Re: [AD] deadlock in 4.3.10plus svn

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Wed, 2008-12-24 at 17:34 +0100, Elias Pschernig wrote:
> I upgraded X11, and now all Allegro programs deadlock. The attached
> patch "fixes" it for me.. should I apply it for now until someone writes
> a proper fix? I don't really know what the problem is, we use pthread
> locks so it *should* work. OTOH waiting inside a lock never is a good
> idea so the current code isn't really ideal either. (In A5 the
> background thread checks for the mapped event and signals a condition
> variable to get the same effect.)
> 

Well, seems to be a bug in X11, specifically XMaskEvent. If I call XSync
and XNextEvent in a loop instead, the MapNotify event eventually
appears. XMaskEvent however will deadlock:

(gdb) info threads
  3 Thread 0x41001950 (LWP 31420)  0x00007ffff6b88a32 in select () from /lib/libc.so.6
  2 Thread 0x40800950 (LWP 31419)  0x00007ffff70251d4 in __lll_lock_wait () from /lib/libpthread.so.0
* 1 Thread 0x7ffff7ece6f0 (LWP 31410)  0x00007ffff70251d4 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff70251d4 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007ffff7023130 in pthread_cond_broadcast@xxxxxxxxxx () from /lib/libpthread.so.0
#2  0x00007ffff7281217 in ?? () from /usr/lib/libX11.so.6
#3  0x00007ffff728158d in ?? () from /usr/lib/libX11.so.6
#4  0x00007ffff7281e49 in _XReadEvents () from /usr/lib/libX11.so.6
#5  0x00007ffff72680ac in XMaskEvent () from /usr/lib/libX11.so.6
#6  0x000000000046279e in _xwin_wait_mapped (win=77594625) at ./src/x/xwin.c:390
#7  0x00000000004635bd in _xwin_private_create_screen (drv=0x6e3320, w=640, h=480, vw=640, vh=480, depth=8, fullscreen=0) at ./src/x/xwin.c:862
#8  0x00000000004636ce in _xwin_create_screen (drv=0x6e3320, w=640, h=480, vw=0, vh=0, depth=8, fullscreen=0) at ./src/x/xwin.c:888
#9  0x000000000049e8ae in _xwin_gfxdrv_init (w=640, h=480, vw=0, vh=0, color_depth=8) at ./src/x/xgfxdrv.c:122
#10 0x00000000004353c4 in init_gfx_driver (drv=0x6e3320, w=640, h=480, v_w=0, v_h=0) at ./src/graphics.c:519
#11 0x0000000000435608 in get_config_gfx_driver (gfx_card=0x7fffffffdf00 "g", w=640, h=480, v_w=0, v_h=0, flags=0, driver_list=0x7060e0)
    at ./src/graphics.c:568
#12 0x0000000000435a54 in _set_gfx_mode (card=0, w=640, h=480, v_w=0, v_h=0, allow_config=-1) at ./src/graphics.c:747
#13 0x00000000004356d2 in set_gfx_mode (card=0, w=640, h=480, v_w=0, v_h=0) at ./src/graphics.c:611
#14 0x0000000000419c4b in main (argc=1, argv=0x7fffffffe478) at ./examples/exunicod.c:160
(gdb) t 2
[Switching to thread 2 (Thread 0x40800950 (LWP 31419))]#0  0x00007ffff70251d4 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff70251d4 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007ffff7020ab0 in _L_lock_102 () from /lib/libpthread.so.0
#2  0x00007ffff70203be in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x000000000048a14c in _unix_lock_mutex (handle=0x706250) at ./src/unix/uthreads.c:362
#4  0x0000000000469cb3 in _xwin_handle_input () at ./src/x/xwin.c:2509
#5  0x0000000000461dd6 in _xwin_bg_handler (threaded=1) at ./src/x/xsystem.c:157
#6  0x0000000000489cb6 in bg_man_pthreads_threadfunc (arg=0x0) at ./src/unix/uthreads.c:102
#7  0x00007ffff701efca in start_thread () from /lib/libpthread.so.0
#8  0x00007ffff6b8f19d in clone () from /lib/libc.so.6
#9  0x0000000000000000 in ?? ()

Now, does it sound like a good idea backporting the A5 mechanisms? It
would require also backporting condition variables. But it's the most
clean way (only one thread processes X11 events).

Otherwise, I can just take this as a good incentive to port everything
to A5, with A4 not working any longer. (Well, I'd keep the patch in my
first post applied locally.)

A third option would be to use an XSync/XNextEvent loop instead of
XMaskEvent. It will eat up the few events until the MapNotify event
which haven't been processed yet by the background thread, but at least
works around the bug.

-- 
Elias Pschernig <elias@xxxxxxxxxx>