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 744043 - GstAudioDecoder: deadlock while seeking
GstAudioDecoder: deadlock while seeking
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-05 13:52 UTC by Christoph Reiter (lazka)
Modified: 2015-02-05 17:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
deadlock trace (68.00 KB, text/plain)
2015-02-05 13:52 UTC, Christoph Reiter (lazka)
Details

Description Christoph Reiter (lazka) 2015-02-05 13:52:13 UTC
stack trace attached; this is on current trunk with the patches applied from bug 741355
Comment 1 Christoph Reiter (lazka) 2015-02-05 13:52:31 UTC
Created attachment 296198 [details]
deadlock trace
Comment 2 Nicolas Dufresne (ndufresne) 2015-02-05 13:59:18 UTC
This looks like a deadlock caused by Python big lock, no the mention base class. Can you explain what you are trying to do ?
Comment 3 Christoph Reiter (lazka) 2015-02-05 14:17:29 UTC
Do you mean because of the PyThread_acquire_lock stuff in the trace? That might be my own locking for gapless playback.. I'll try to reproduce without it.

I'm currently fuzzing playbin (random seeking, song change, different formats) because I regularly get bug reports about deadlocks in GStreamer.

Thanks
Comment 4 Nicolas Dufresne (ndufresne) 2015-02-05 14:29:51 UTC
(In reply to comment #3)
> Do you mean because of the PyThread_acquire_lock stuff in the trace? That might
> be my own locking for gapless playback.. I'll try to reproduce without it.
> 
> I'm currently fuzzing playbin (random seeking, song change, different formats)
> because I regularly get bug reports about deadlocks in GStreamer.

Whith pyhton and the way the bindings are integrated, this is what we get if you let the streaming thread sneak in. If you can, stay away from the streaming thread and you won't have issues. Doing stuff from the streaming thread, even without need care. Maybe I close this bug ?
Comment 5 Nicolas Dufresne (ndufresne) 2015-02-05 14:30:30 UTC
(* even without pythont, need care)
Comment 6 Christoph Reiter (lazka) 2015-02-05 14:37:03 UTC
Yeah, I can't reproduce without gapless playback.

I kinda need to do stuff in the streaming thread for handling playbin::about-to-finish. Seems there is a problem there.

Could it be that it's not allowed to seek while the playbin::about-to-finish handler is active?

Thanks for having a look at this. Feel free to close.
Comment 7 Christoph Reiter (lazka) 2015-02-05 14:43:19 UTC
OK, I see quite a few potential issue there. Closing this. Thanks again.
Comment 8 Nicolas Dufresne (ndufresne) 2015-02-05 14:59:39 UTC
Thank you. about-to-finish callback is indeed on the streaming thread. The only thing I'm sure you can do is to set a new URI from there. Operating a flushing seek won't work, operating a non-flushing seek might be worth a test (at least in C). You could use a gmainloop in python, and fired a high priority idle, so you endup operating the pipeline from the main thread.
Comment 9 Christoph Reiter (lazka) 2015-02-05 15:22:40 UTC
(In reply to comment #8)
> You could use a gmainloop in python, and fired a high priority idle, so
> you endup operating the pipeline from the main thread.

I'm currently using the mainloop and only set the uri in the handler. I meant seeking in the mainloop while the handler is waiting for the uri to be set (I have to block in the handler until the result in the mainloop is ready..)
Comment 10 Christoph Reiter (lazka) 2015-02-05 15:41:31 UTC
Ok, I can't seem to make it work. Could it be that while about-to-finish is running with some locks are held which block sending seek events and setting state?
Comment 11 Nicolas Dufresne (ndufresne) 2015-02-05 16:33:06 UTC
It's called with the stream-lock, which is a recursive lock. Adding another lock without control over the lock order leads to deadlock. Please though, use the mailing list, we don't do support on bugs.
Comment 12 Christoph Reiter (lazka) 2015-02-05 17:10:32 UTC
(In reply to comment #11)
> It's called with the stream-lock, which is a recursive lock. Adding another
> lock without control over the lock order leads to deadlock.

I see, thanks. I've now "solved" it by adding a timeout to the locking.

> Please though, use
> the mailing list, we don't do support on bugs.

Ok, sorry, will do.