[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