[Mesa3d-dev] Bug in mesa-master: Deadlock for multi-threaded glx apps inside __glXInitialize()

[Mario K. <mar...@tu...>]

Think i sent it to the wrong mailing list. Here we go again...

Begin forwarded message:

> From: Mario Kleiner <mar...@tu...>
> Date: July 27, 2010 2:56:04 AM GMT+02:00
> To: Kristian Hogsberg <kr...@bi...>, xor...@li...
> Subject: Bug: Deadlock for multi-threaded glx apps inside  
> __glXInitialize()
>
> Hi Kristian
>
> Testing with current mesa master, my toolkit deadlocks on the first  
> call to a glX function (glXChooseVisual()).
>
> The deadlock was probably introduced by your recent commit:
>
> "glx: Use _Xglobal_lock for protecting extension display list"
>
> ab434f6b7641a64d30725a9ac24929240362d466
>
> The problem is that the _Xglobal_lock is locked twice inside the  
> __glXInitialize() function of mesa/src/glx/glxext.c, once inside  
> __glXInitialize(), and then as part of dri2CreateDisplay() -> ... - 
> > XextFindDisplay. The 2nd locking call on the already held lock  
> deadlocks.
>
> Attached a backtrace with the problem and a patch/hack that "fixes"  
> it for me, but introduces a race-condition itself, so this is  
> obviously not the correct solution. The race condition would  
> trigger if two threads would simultaneously do their first call to  
> a glX function for the same Display* dpy handle, rather unlikely to  
> happen in practice? If so, then the patch might be  an acceptable  
> fix until a better solution is found?
>
> Other applications (glxgears, games etc.) work correctly. The  
> difference is that my toolkit calls  XInitThreads() at startup to  
> use xlib multi-threaded and afaik the locking calls only get  
> enabled if xlib is switched to thread-safe mode, otherwise they are  
> no-ops? If i omit XInitThreads() everything works again.
>
> thanks,
> -mario
>