[MPlayer-users] [Bug report] Interrupting xvmc playback may result in deadlock.
Rich Felker
dalias at aerifal.cx
Wed Dec 20 16:36:41 CET 2006
On Mon, Dec 18, 2006 at 12:53:18PM +0100, Thomas Hellström wrote:
> Version:
> SVN as of today.
> Summary:
> When used with certain XvMC libraries that use non-recursive pthread
> mutexes to protect data in multithreaded environments, a deadlock can
> occur when mplayer exits as the result of a terminating signal.
> What happens is that the mutex may be held by the main thread, when
> mplayer as part of the signal handler calls the xvmc uninit function.
> This function calls the XvMC library recursively, trying to lock the
> mutex again, and this results in a deadlock.
> XvMC libraries are not guaranteed to be reentrant.
> Fix:
> I have attached an extremely ugly workaround that sets a global variable
> to indicate when execution is part of a signal handler. In that case,
> the XvMC library is never called. We can do this because when mplayer
> exits, the X server will do all necessary XvMC cleanup. Note: This patch
> is just to illustrate the problem. It's possible that gmplayer needs
> fixing too, and it's also possible that there is a much cleaner solution.
Your solution is backwards. Instead you should put a static variable
in vo_xvmc to indicate if you're in an xvmc call, and if so, refuse to
perform the uninit and just return.
Rich
More information about the MPlayer-users
mailing list