After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 706551 - gsttestclock check failed
gsttestclock check failed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.1.3
Other Linux
: Normal normal
: 1.2.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-08-22 03:47 UTC by kel
Modified: 2013-09-19 15:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gsttestclock_error_log (1.25 KB, text/plain)
2013-08-22 03:48 UTC, kel
Details

Description kel 2013-08-22 03:47:28 UTC
using gstreamer-1.1.3.tar.xz on http://gstreamer.freedesktop.org/src/gstreamer/

1.add the libs and then 
./configure --enable-docbook --enable-gtk-doc

2.run make
make

3.run make check
make check

and then 

============================================================================
Testsuite summary for GStreamer 1.1.3
============================================================================
# TOTAL: 84
# PASS:  83
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/check/test-suite.log
Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
============================================================================


the fail is libs/gsttestclock, and the attach is the error log.


my environment is ubuntu 12.04, kernel version is 3.2.0-29-generic-pae.
Comment 1 kel 2013-08-22 03:48:47 UTC
Created attachment 252692 [details]
gsttestclock_error_log
Comment 2 Sebastian Dröge (slomo) 2013-08-22 08:23:23 UTC
Must be a very subtle race condition. Does it fail for you every time? Even when running it in gdb? (make libs/gsttestclock.gdb in tests/check)

I'm running make libs/gsttestclock.forever since 10 minutes without problems now.
Comment 3 kel 2013-08-22 09:07:55 UTC
(In reply to comment #2)
> Must be a very subtle race condition. Does it fail for you every time? Even
> when running it in gdb? (make libs/gsttestclock.gdb in tests/check)
> 
> I'm running make libs/gsttestclock.forever since 10 minutes without problems
> now.

it fails every time when i try to run 'make check'. but after trying to ignore the error, install the gstreamer, and play a sample video, it seems that the video can be played normally, only except for this following message:

There may be a timestamping problem, or this computer is too slow.


when try to run it in gdb(make libs/gsttestclock.gdb in tests/check), the error occurs 

(gdb) r
Starting program:~/gstreamer-1.1.3/tests/check/libs/.libs/lt-gsttestclock 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Running suite(s): GstTestClock
[New Thread 0x406ddb40 (LWP 28080)]
**
ERROR:libs/gsttestclock.c:284:test_wait_synchronous_no_timeout: assertion failed: (entry == (clock_id))

Program received signal SIGABRT, Aborted.
0x40022424 in __kernel_vsyscall ()
(gdb) 



the same error in the log?
Comment 4 Sebastian Dröge (slomo) 2013-08-22 09:35:44 UTC
The testclock is not used in real world usage. This would seem like there is a general clock problem on your system, like the systemclock being completely unreliable.
Comment 5 kel 2013-08-23 02:57:38 UTC
(In reply to comment #4)
> The testclock is not used in real world usage. This would seem like there is a
> general clock problem on your system, like the systemclock being completely
> unreliable.


1.try to run ntpdate to fix the time, it seems that ntpdate works correctly with the ubuntu server.

$ sudo ntpdate ntp.ubuntu.com
23 Aug 08:53:43 ntpdate[4943]: adjust time server 91.189.89.199 offset 0.023004 sec


2.run in gdb mode(make libs/gsttestclock.gdb in tests/check), and the first error is in line 432

432	    g_cond_wait (&priv->entry_processed_cond, GST_OBJECT_GET_LOCK (test_clock));
(gdb) 
**
ERROR:libs/gsttestclock.c:284:test_wait_synchronous_no_timeout: assertion failed: (entry == (clock_id))

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x404dc900 (LWP 16438)]
0x40022424 in __kernel_vsyscall ()


and the values are:


(gdb) l
427	    gst_test_clock_add_entry (test_clock, entry, jitter);
428	
429	  GST_CLOCK_ENTRY_STATUS (entry) = GST_CLOCK_BUSY;
430	
431	  while (GST_CLOCK_ENTRY_STATUS (entry) == GST_CLOCK_BUSY)
432	    g_cond_wait (&priv->entry_processed_cond, GST_OBJECT_GET_LOCK (test_clock));
433	
434	  GST_OBJECT_UNLOCK (test_clock);
435	
436	  return GST_CLOCK_ENTRY_STATUS (entry);

(*here is the problem?*)

(gdb) p *entry
$4 = {refcount = 3, clock = 0x806f5b0, type = GST_CLOCK_ENTRY_SINGLE, time = 999999999, 
  interval = 18446744073709551615, status = GST_CLOCK_BUSY, func = 0, user_data = 0x0, destroy_data = 0, 
  unscheduled = 0, woken_up = 0, _gst_reserved = {0x0, 0x0, 0x0, 0x0}}

(gdb) p priv->entry_processed_cond
$5 = {p = 0x806ed78, i = {0, 0}}

(gdb) p *test_clock
$6 = {parent = {object = {object = {g_type_instance = {g_class = 0x806e7b0}, ref_count = 1, qdata = 0x0}, lock = {
        p = 0x806eb80, i = {134671232, 0}}, name = 0x806ee18 "testclock6", parent = 0x0, flags = 240, 
      control_bindings = 0x0, control_rate = 100000000, last_sync = 18446744073709551615, _gst_reserved = 0x0}, 
    priv = 0x806f600, _gst_reserved = {0x0, 0x0, 0x0, 0x0}}, priv = 0x806f668}



still reading the code(/tests/check/libs/gsttestclock.c).
Comment 6 Olivier Crête 2013-09-17 20:28:18 UTC
ntpdate won't help as testclock is an entirely fake clock (it doesn't use the system clock or any other clock for that matter).

The assertion also doesn't match the line on which you breaking? Can you try doing "make clean && make all && make check" again ?
Comment 7 Tim-Philipp Müller 2013-09-19 15:46:10 UTC
commit cc4ba028ff8c80110094017ff8159b6b9f5e7440
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Thu Sep 19 16:43:18 2013 +0100

    check: testclock: don't put code with side-effects in g_assert()
    
    Fixes unit test failures when -DG_DISABLE_ASSERT is used.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=706551