<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hello,<br>
<br>
Recent change in git master have brought a regression with skins2, that
may point out a deeper design issue and wider questions.<br>
<br>
<br>
<u>Test case for regression</u><br>
<br>
- start 'vlc -I skins --no-video'<br>
- play an item<br>
- quit vlc (while playing is underway)<br>
<br>
vlc then crashes in input_resource_HoldAout with :<br>
<br>
<i>LibVLC fatal error locking mutex (22) in thread 29236 at
misc/pthread.c:223 in vlc_mutex_lock</i><br>
<br>
which means that we try to use an already deallocated mutex (the
lock_hold for resource)<br>
<br>
Note that --no-video is important in this test case. Otherwise,
resource seems to be kept accessible longer, and no crash occurs.<br>
<br>
<br>
<u>Cause for the problem<br>
</u><br>
Actually, during playlist deactivation, the current input thread is
joined, the input object is released and resource is deallocated. Yet,
the input object is still held by some other parts of vlc (the skins2
interface and the qt4 dialog provider) , and resource is a key part of
the input object for input_GetAout, input_GetVout, .... helper
functions to succeed. As long as an input is not truly deallocated,
resources should be accessible, since we need them to remove callbacks
on aout/vout <br>
<br>
<br>
<u>Wider Reflection</u><br>
<br>
>From the perspective of an interface developer, the vlc core may be a
bit complicated. We need to retrieve the playlist object, then
successive inputs, then aout or vout to add callbacks on all of them.
Since aout/vout reuse, it is even trickier in a sense that not all
variables are reset on a per input basis (see the audio equalizer). I
always wondered why a single object (playlist, media player for libvlc
or vlm manager) would not host all exported variables worth of interest
for interface. Actually, aout/vout or successive inputs for a playlist
should be kept as an internal implementation, not something interface
developers must be aware of. Because of all these different objects,
interfaces need to retain references or retrieve them with
input_GetAout .... to properly remove callbacks. That may actually
conflict with the way vlc core wishes to deallocate things. If
interfaces were to handle only a single object, then all the complexity
would be mutualized in a single place (at vlc core), instead of in all
interfaces (qt4, skins, ....). This single object (playlist, media
player, vlm manager) could be just a proxy for the already existing
input/aout/vout objects and related variables.<br>
<br>
<br>
Since some work is currently being done in this matter, I hope this
email can be of any help..<br>
<br>
Regards<br>
Erwan10<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>