Created attachment 37248 [details] [review]
Make global GLX mutex recursive.

Sigh.  Here's a horrible, horrible hack that should get the game working until
someone who understands mesa locking comes up with a better idea.

Looks like if a dri2 context is destroyed while a swap event is pending (seems
to happen easily if there are two contexts in one application, maybe it only
happens in this case?), we get a deadlock.  The garbage collector is called
while holding the global glx mutex, which calls XSync, which tries to handle
the pending swap event, which tries to take the mutex --> boom.

Looking at the code, it doesn't seem like this is entirely a new problem,
either: invalidate events also take the global mutex in DRI2WireToEvent and I
imagine they can cause a similar deadlock.

There's nothing radeon-specific about this, every DRI2 driver should be
affected.

(In reply to comment #1)
> 
> Sigh.  Here's a horrible, horrible hack that should get the game working until
> someone who understands mesa locking comes up with a better idea.

The patch works fine here, thanks for taking the time to fix this!
 
> There's nothing radeon-specific about this, every DRI2 driver should be
> affected.

Thanks for confirming, where should it be reassigned to, Mesa core?

Created attachment 37255 [details]
Test case.

A test case which reliably reproduces this issue for me.  Since there's
a race involved, the amount of time required to lock up varies.

It works by creating two contexts for subwindows of a larger parent window,
then repeatedly drawing on each and destroying/recreating one of the contexts
every iteration.

Can you try again with latest git?  I think this might be fixed now.

Yes, seems to work fine now, thanks!