[vlc-devel] LibVLC fatal error

[Rémi Denis-Courmont]

Le Sunday 16 March 2008 00:50:38 Pierre d'Herbemont, vous avez écrit :
> > This looks like a bug in libvlc, the line 794 try to lock a mutex, which
> > should have been initialized at the very beginning of input creation.
>
> There is an known bug of libvlc with input. Basically input refcount-ing is
> badly done and you can end up in vlc_object_find() a destroyed
> input_thread_t. I am not sure this is this bug or a nasty work around that
> causes this. But I was working on object refcounting sanitization, which
> fixed most of the input related crash.

The issue lies in being able to "find" an object before it's been fully 
initialized, or after it's started being cleaning up. That is not 
input-specific, I believe.

In principle, vlc_object_attach() and vlc_object_detach() would take care of 
it. In practice, this fails, first because object are customarily attached 
too early (I believe it's needed for VLC variables to work), and second 
because detaching fails to _wait_ for the object to be fully released. I 
doubt these two problems could be fixed non-disruptively.

> Basically vlc_object_release() should call input_Destroy() if its refcount
> reaches zero, after the object has been removed from the object list.
> Currently it's is done the other way around, which doesn't work in most
> situation. (input_Destroy calls vlc_object_release()).

Can be done with a destroy callback, but would need to be very careful what 
the calback can do - same problem as garbage collection handlers in other 
languages. In particular, it could not interact with any other object 
(directly NOR indirectly).

-- 
Rémi Denis-Courmont
http://www.remlab.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080316/5d8fd1cf/attachment.sig>