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 646992 - [playbin2] - deadlock when setting pipeline to STATE_NULL
[playbin2] - deadlock when setting pipeline to STATE_NULL
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.32
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-04-07 06:52 UTC by Marlène Jacquier
Modified: 2011-04-12 11:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Avi file (8.90 KB, text/plain)
2011-04-07 06:52 UTC, Marlène Jacquier
Details
TS file (5.59 KB, text/plain)
2011-04-07 06:52 UTC, Marlène Jacquier
Details

Description Marlène Jacquier 2011-04-07 06:52:10 UTC
Created attachment 185388 [details]
Avi file

I'm new to gstreamer framework.
I'm using playbin2 element in a media player application with fakesink elements for video and audio sinks.
I'm running this application on an embedded system with HW accelerated video and audio decoders.

When I quit the application, sometimes I enter a deadlock. I can reproduce it with different file container, meaning different demuxers elements.
It's happening almost everytime with avi files and sometimes after a while (1 or 2 minutes) it finally ends.

In attachment here are the backtraces from debugger, the application is stuck on a mutex lock.

I looked in the bugzilla and I found two similar bugs :
https://bugzilla.gnome.org/show_bug.cgi?id=574293
https://bugzilla.gnome.org/show_bug.cgi?id=572577
But they seem to have been fixed.

I really don't know where to look at to fix this issue, if you have any ideas...
Comment 1 Marlène Jacquier 2011-04-07 06:52:34 UTC
Created attachment 185389 [details]
TS file
Comment 2 Håvard Graff (hgr) 2011-04-08 21:33:42 UTC
To me it looks like the pad is blocked. We had a similar issue where we would handle a "pad-added" signal async, by blocking the pad and marshaling the signal onto the MainContext, but if the state-change was spun after the pad was blocked, but before the signal, we would get a callstack like this one...

I don´t know playbin2, but if it uses pad-blocking anywhere, and the state-change are able to get in between the blocking and the unblocking, you could get something similar to this callstack.
Comment 3 bcxa.sz 2011-04-11 03:42:31 UTC
the patch in https://bugzilla.gnome.org/show_bug.cgi?id=572577 is not integrated into the gstreamer official version yet. Please test to see whether it get fixed.
Comment 4 bcxa.sz 2011-04-11 03:49:36 UTC
(In reply to comment #3)
> the patch in https://bugzilla.gnome.org/show_bug.cgi?id=572577 is not
> integrated into the gstreamer official version yet. Please test to see whether
> it get fixed.


Sorry, it has been integrated.
Comment 5 bcxa.sz 2011-04-11 03:54:42 UTC
The patch in https://bugzilla.gnome.org/show_bug.cgi?id=572577 has been integrated partially. The code related to 'fakesink' is not integrated.

See patch line 15, 112, 113, 114,144, ...
Comment 6 bcxa.sz 2011-04-11 04:05:47 UTC
(In reply to comment #5)
> The patch in https://bugzilla.gnome.org/show_bug.cgi?id=572577 has been
> integrated partially. The code related to 'fakesink' is not integrated.
> See patch line 15, 112, 113, 114,144, ...

it seemed the fix has been implemented with another way in gst-plugins-base-0.10.32.
Comment 7 Marlène Jacquier 2011-04-11 05:59:23 UTC
I've already seen this bugzilla, and checked it was already integrated (apart from the fakesink part).

How to track that the state-change signal arrives after a pad blocking in playbin2? And how to fix this?
Comment 8 Marlène Jacquier 2011-04-12 11:08:48 UTC
There was a blocking command in our decoder elements that was causing this mutex lock inside playbin2.