[vlc-devel] Deadlock on stop
Romain Vimont | ®om
rom at rom1v.com
Wed Apr 30 17:11:50 CEST 2014
Absolutely, so the problem is that the input thread does not finish.
After some investigations, I discovered that this is due to race
conditions after calls to vlc_object_alive(). Moreover, this function
has an explicit comment (src/misc/objects.c):
* This function returns true, except when it returns false.
* \warning Do not use this function. Ever. You were warned.
bool vlc_object_alive(vlc_object_t *obj)
The deadlock does not happen always at the same place, but always after
a call to vlc_object_alive().
For instance, in AStreamPrebufferBlock() (src/input/stream.c), the call
to AReadBlock() sometimes never ends, when vlc_object_alive() returns 1
and the "stopping thread" is calling ObjectKillChildrens(), so there is
no input data anymore (so AReadBlock() waits forever).
Although, this ObjectKillChildrens() have a reassuring comment too:
/* FIXME ObjectKillChildrens seems a very bad idea in fact */
Another example, the deadlock may occur during the call to
p_demux->pf_demux(p_demux) after vlc_object_alive() in Open() of
I think we need more than an atomic flag (currently "alive" in "struct
vlc_object_internals"): we need to be able to interrupt AReadBlock() on
stop (and other blocking functions which are currently called after a
test to vlc_object_alive()).
What do you think?
Le vendredi 25 avril 2014 à 19:11 +0300, Rémi Denis-Courmont a écrit :
> Le vendredi 25 avril 2014, 15:13:22 Romain Vimont | ®om a écrit :
> > I guess there should be a call to vlc_sem_post() somewhere to wake it
> > up… Maybe you have an idea?
> It's in finish_joinable_thread().
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel