wfdb icon indicating copy to clipboard operation
wfdb copied to clipboard

WAVE freezes at startup with Xlib 1.8.4

Open bemoody opened this issue 1 year ago • 0 comments
trafficstars

If you try to run WAVE on Debian 12 (libx11-6=2:1.8.4-2+deb12u2), using the old Debian XView package (xviewg=3.2p1.4-28.2), it will freeze (nothing displayed, no error message.) The same is true for all XView programs.

Helgrind helps explain why:

==3510384== Thread #1 unlocked a not-locked lock at 0x5F734D0
==3510384==    at 0x48487BE: mutex_unlock_WRK (hg_intercepts.c:1179)
==3510384==    by 0x4A5E1EA: _XUnlockDisplay (locking.c:245)
==3510384==    by 0x4A71336: _XAllocIDs (xcb_io.c:639)
==3510384==    by 0x495E9F1: server_init (server.c:791)
==3510384==    by 0x49A55B1: xv_create_avlist (xv.c:391)
==3510384==    by 0x49A57A0: xv_create (xv.c:307)
==3510384==    by 0x49A6D87: xv_init (xv_init.c:308)
==3510384==    by 0x122C56: ??? (in /usr/local/bin/wave)
==3510384==    by 0x10BDDE: ??? (in /usr/local/bin/wave)
==3510384==    by 0x4BAB2D4: (below main) (libc_start_call_main.h:58)

...

==3510384== Thread #1: Attempt to re-lock a non-recursive lock I already hold
==3510384==    at 0x484839E: mutex_lock_WRK (hg_intercepts.c:932)
==3510384==    by 0x4A5E278: _XLockDisplay (locking.c:470)
==3510384==    by 0x4A5B25F: XInternAtom (IntAtom.c:175)
==3510384==    by 0x495EA95: server_init_atoms (server.c:1564)
==3510384==    by 0x495EA95: server_init (server.c:822)
==3510384==    by 0x49A55B1: xv_create_avlist (xv.c:391)
==3510384==    by 0x49A57A0: xv_create (xv.c:307)
==3510384==    by 0x49A6D87: xv_init (xv_init.c:308)
==3510384==    by 0x122C56: ??? (in /usr/local/bin/wave)
==3510384==    by 0x10BDDE: ??? (in /usr/local/bin/wave)
==3510384==    by 0x4BAB2D4: (below main) (libc_start_call_main.h:58)
==3510384==  Lock was previously acquired
==3510384==    at 0x4848412: mutex_lock_WRK (hg_intercepts.c:942)
==3510384==    by 0x4A5E3DC: _XInternalLockDisplay (locking.c:504)
==3510384==    by 0x4A7137A: _XAllocIDs (xcb_io.c:644)
==3510384==    by 0x495E9F1: server_init (server.c:791)
==3510384==    by 0x49A55B1: xv_create_avlist (xv.c:391)
==3510384==    by 0x49A57A0: xv_create (xv.c:307)
==3510384==    by 0x49A6D87: xv_init (xv_init.c:308)
==3510384==    by 0x122C56: ??? (in /usr/local/bin/wave)
==3510384==    by 0x10BDDE: ??? (in /usr/local/bin/wave)
==3510384==    by 0x4BAB2D4: (below main) (libc_start_call_main.h:58)

I'd never heard of XAllocID or XAllocIDs before today. It seems like these functions are meant to be used by extension libraries but not really meant to be used by applications. I don't know why XView uses them, but it's hardly the weirdest thing XView does.

Anyway, it seems that in multithreaded applications, XAllocID/XAllocIDs are only supposed to be called while the server is locked via XLockDisplay.

WAVE doesn't use threads at all, let alone using Xlib from multiple threads. But apparently starting with version 1.8, Xlib makes multithread support mandatory. (And judging by debian/changelog, this has broken other programs and has been repeatedly reverted and un-reverted by the Debian maintainers.)

The extremely quick and dirty kludge is to stub out XInitThreads and XFreeThreads:

Status XInitThreads() { return 0; }
Status XFreeThreads() { return 0; }

But a better idea would be to fix it in XView, or somehow make Xlib backward compatible.

See also https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157 (other things broken by XInitThreads-by-default.)

See also https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/129 (somebody wanting to port XView to amd64; I wish them luck.)

bemoody avatar Jun 05 '24 21:06 bemoody