Created attachment 296198 [details]
deadlock trace

This looks like a deadlock caused by Python big lock, no the mention base class. Can you explain what you are trying to do ?

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

(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 ?

(* even without pythont, need care)

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.

OK, I see quite a few potential issue there. Closing this. Thanks again.

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.

(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..)

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?

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.

(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.