GNOME Bugzilla – Bug 378770
[xvimagesink] race condition in event thread?
Last modified: 2007-10-22 10:21:55 UTC
That bug has been opened on https://launchpad.net/bugs/73106
"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"
987 while (XCheckWindowEvent (xvimagesink->xcontext->disp,
(gdb) p xvimagesink->xwindow
$1 = (GstXWindow *) 0x0
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.
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.
*** Bug 425413 has been marked as a duplicate of this bug. ***
* sys/ximage/ximagesink.c: (gst_ximagesink_event_thread),
* sys/xvimage/xvimagesink.c: (gst_xvimagesink_event_thread),
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.