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 378770 - [xvimagesink] race condition in event thread?
[xvimagesink] race condition in event thread?
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal critical
: 0.10.15
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 425413 (view as bug list)
Depends on:
Reported: 2006-11-24 09:30 UTC by Sebastien Bacher
Modified: 2007-10-22 10:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16

Description Sebastien Bacher 2006-11-24 09:30:50 UTC
That bug has been opened on

"It hung up and then crashed. What did i try to do? I tried to open an mp3 file being sent to a bluetooth device at the same time. Opened the file again and it worked.
Totem generated crash report"

Debug backtrace:

987       while (XCheckWindowEvent (xvimagesink->xcontext->disp,
(gdb) bt
  • #0 gst_xvimagesink_event_thread
    at xvimagesink.c line 987
  • #1 g_thread_create_proxy
    at gthread.c line 553
  • #2 start_thread
    from /lib/tls/i686/cmov/
  • #3 clone
    from /lib/tls/i686/cmov/

From gdb:

(gdb) p xvimagesink->xwindow
$1 = (GstXWindow *) 0x0
Comment 1 Tim-Philipp Müller 2007-05-04 11:35:53 UTC
Looks like a race condition somewhere with the event thread and clearing or setting the xwindow/context; quite a bit of extra locking has been added in the last release(s), but after a quick glance at the code I'm not 100% convinced yet that there aren't races left or that the right locks are taken.

Leaving for someone more familiar with the xvimagesink code to have a look at.
Comment 2 Wim Taymans 2007-10-17 15:02:44 UTC
it's pretty racy indeed, and all over the place. Some notes:

 - shutdown, the thread is joined *after* setting variables to NULL which are used
   in the thread.
 - the event thread checks a variable ->running without taking the object lock.
 - the event thread does some more stuff without taking the lock. This could be
   fine if you can guarantee that all fields have a non-null value while the
   thread is running.
 - when the event thread is started (in many places but usually in NULL->READY),
  ->running is still FALSE, which can possibly make the thread stop immediatly.
Comment 3 Wim Taymans 2007-10-17 15:08:58 UTC
*** Bug 425413 has been marked as a duplicate of this bug. ***
Comment 4 Wim Taymans 2007-10-22 10:21:55 UTC
        * sys/ximage/ximagesink.c: (gst_ximagesink_event_thread),
        (gst_ximagesink_xcontext_get), (gst_ximagesink_xcontext_clear),
        (gst_ximagesink_change_state), (gst_ximagesink_reset):
        * sys/xvimage/xvimagesink.c: (gst_xvimagesink_event_thread),
        (gst_xvimagesink_xcontext_get), (gst_xvimagesink_xcontext_clear),
        (gst_xvimagesink_change_state), (gst_xvimagesink_reset):
        Make sure that before we clean up the X resources, we shutdown and join
        the event thread.
        Also make sure the event thread does not shut down immediatly after
        startup because the running variable is not yet correctly set.
        Fixes #378770.