[vlc-devel] Deadlock on stop

[Romain Vimont | ®om]

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
modules/demux/ts.c.

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
> http://www.remlab.net/
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel