[vlc-devel] LibVLC fatal error
rdenis at simphalempin.com
Sun Mar 16 10:10:08 CET 2008
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the vlc-devel