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 681015 - discoverer: deadlock race on video files - typefind + avidemux both in set_state
discoverer: deadlock race on video files - typefind + avidemux both in set_state
Status: RESOLVED DUPLICATE of bug 690420
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 669826 (view as bug list)
Depends on:
Blocks: 679757
 
 
Reported: 2012-08-01 18:59 UTC by René Stadler
Modified: 2013-03-02 23:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test script (734 bytes, text/x-python)
2012-08-01 18:59 UTC, René Stadler
Details
Backtrace (7.37 KB, text/plain)
2012-08-01 22:45 UTC, René Stadler
Details

Description René Stadler 2012-08-01 18:59:52 UTC
Created attachment 220097 [details]
Test script

Running gst-discoverer-1.0 on some video files will sometimes deadlock. It can take a while to reproduce, but it's really there (just run it in an endless loop). Using discoverer from C seems to be the hardest way to reproduce (probably why such a bug is there).

Jeff wrote a little python script that does the same. It is a bit easier to reproduce with that. Probably because Python.

The sure way to reproduce is however with pitivi. The previewer in the file chooser triggers it 100% of the time. When we disabled that, the discoverer run afterwards has maybe a 1 in 20 chance of it *working* (so it will work rarely actually). Use the pygi branch from git://github.com/nekohayo/pitivi.git if needed.

BTW, doesn't matter if discoverer runs async or not.
Comment 1 Tim-Philipp Müller 2012-08-01 22:10:11 UTC
Stack trace of all threads when deadlocked?
Comment 2 René Stadler 2012-08-01 22:45:52 UTC
Created attachment 220107 [details]
Backtrace

There are slightly different ways to hang, but this is the most common one with gst-discoverer-1.0.
Comment 3 Jean-François Fortin Tam 2012-08-03 13:00:41 UTC
Actually, I already experienced this problem months ago, except that with static bindings it was much more rare: bug #669826.

René suspects that the callback for registry::feature-added in gobject introspection slows it down enough to trigger the bug 90% of the time. With pygst, this was probably a bit faster to execute and the race was thus less likely to occur.
Comment 4 Jean-François Fortin Tam 2012-08-15 13:55:49 UTC
This race almost seems like a "phase of the moon" bug. I hit that deadlock continously for three days while investigating it with René, then the week-end after that I was unable to reproduce it, then during the week I was able to experience it again sometimes, then didn't see signs of it until yesterday...

Yesterday, I updated and recompiled all my gstreamer 1.0 checkouts after Wim reported bug #681535 as fixed. As soon as I did that, I now had a segfault everytime the discoverer was involved (when trying to import clips, or preview them in the import dialog, or load a project). I thought I'd get a backtrace this morning, but today I'm again unable to reproduce it (even outside gdb). Urgh.
Comment 5 Murray Cumming 2012-12-21 09:24:23 UTC
I guess this is a duplicate of bug #690420 which Tim-Philipp Müller is making progress on.
Comment 6 Jean-François Fortin Tam 2012-12-21 17:07:38 UTC
I'm not 100% sure, as I recall seeing such lockups -- that were probably due to the discoverer -- prior to pitivi switching to gstreamer 1.x and gobject introspection. I may be wrong though, and at this point, on my side, we're not switching "back" to 0.10.
Comment 7 Tim-Philipp Müller 2012-12-22 12:22:31 UTC
Judging by the stack trace, it's the same issue. Please re-open if you still get this with git master, and provide a new stack trace then.

*** This bug has been marked as a duplicate of bug 690420 ***
Comment 8 Jean-François Fortin Tam 2013-03-02 23:59:56 UTC
*** Bug 669826 has been marked as a duplicate of this bug. ***