devdraw: hang on Linux (acme)

[ghost]

I can't reproduce it easily, but it does happen every day.

(gdb) thread apply all bt

Thread 2 (Thread 0x7fb0bdd21700 (LWP 2760)):
#0  0x00007fb0bdf30eec in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00005601c64a0d24 in _procsleep (r=0x5601c6c3b218) at pthread.c:60
#2  0x00005601c64a21bb in procscheduler (p=0x5601c6c3b0f0) at thread.c:441
#3  0x00005601c64a1a71 in _threadswitch () at thread.c:259
#4  0x00005601c64a292b in threadqlock (l=0x5601c64d4420 <xlk>, block=0x1, pc=0x5601c6489775) at thread.c:622
#5  0x00005601c64a6e91 in qlock (l=0x5601c64d4420 <xlk>) at qlock.c:56
#6  0x00005601c6489775 in xlock () at x11-screen.c:137
#7  0x00005601c648d595 in __xputsnarf (data=0x7fb0b80d5616 "/usr/share/doc/kdump-tools/copyright\n/usr/share/man") at x11-screen.c:1557
#8  0x00005601c648da24 in rpc_putsnarf (data=0x7fb0b80d5616 "/usr/share/doc/kdump-tools/copyright\n/usr/share/man") at x11-screen.c:1743
#9  0x00005601c6487479 in runmsg (c=0x5601c6c2b170, m=0x7fb0bdd20c90) at srv.c:288
#10 0x00005601c6486e88 in serveproc (v=0x5601c6c2b170) at srv.c:168
#11 0x00005601c64a1f5a in procmain (p=0x5601c6c3b0f0) at thread.c:384
#12 0x00005601c64a0e3a in startprocfn (v=0x5601c6c2ee70) at pthread.c:99
#13 0x00007fb0bdf2afa3 in start_thread () from /lib/libpthread.so.0
#14 0x00007fb0bde5c1af in clone () from /lib/libc.so.6

Thread 1 (Thread 0x7fb0bdd23180 (LWP 2759)):
#0  0x00007fb0bdf30eec in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00005601c64a0d24 in _procsleep (r=0x5601c6c2a3a8) at pthread.c:60
#2  0x00005601c64a21bb in procscheduler (p=0x5601c6c2a280) at thread.c:441
#3  0x00005601c64a1a71 in _threadswitch () at thread.c:259
#4  0x00005601c64a292b in threadqlock (l=0x5601c64d7ce0 <clip>, block=0x1, pc=0x5601c648d868) at thread.c:622
#5  0x00005601c64a6e91 in qlock (l=0x5601c64d7ce0 <clip>) at qlock.c:56
#6  0x00005601c648d868 in _xselect (e=0x7ffe6f295540) at x11-screen.c:1602
#7  0x00005601c648a523 in runxevent (xev=0x7ffe6f295540) at x11-screen.c:478
#8  0x00005601c6489fd0 in xloop () at x11-screen.c:310
#9  0x00005601c6489d5f in gfx_main () at x11-screen.c:274
#10 0x00005601c6486ae7 in threadmain (argc=0x2, argv=0x7ffe6f295880) at srv.c:85
#11 0x00005601c64a2f14 in threadmainstart (v=0x0) at thread.c:813
#12 0x00005601c64a1f5a in procmain (p=0x5601c6c2a280) at thread.c:384
#13 0x00005601c64a312f in p9main (argc=0x3, argv=0x7ffe6f295878) at thread.c:871
#14 0x00005601c64a575c in main (argc=0x3, argv=0x7ffe6f295878) at main.c:10

From what I see, on the second thread, __xputsnarf() does:

qlock(&clip.lk);
xlock();

but on first thread, xloop() takes xlock() and _xselect() calls qlock(&clip.lk).

It does look like https://github.com/9fans/plan9port/issues/347 (meaning, white window in full screen with no reaction to mouse events). I didn't try to fix it by calling xunlock()/xlock() around XChangeProperty() yet.

[ghost]

I'm using this version: 951446a77417743b8ed900cb1b5a1ae08522840e

[ghost]

I give up trying to make a proper PR. This (https://github.com/9fans/plan9port/commit/faa533e2e54e7fa8704ced6b0eff847cdaf839a0) is the commit done as @rsc suggested on https://github.com/9fans/plan9port/pull/443.