Created attachment 40760 [details] xbindkeys -n crash log xbindkeys crashes after two bound keypresses if the version of libx11 is 1.4. Downgrading libx11 makes this behavior go away. I am not sure if the source of the bug is in libx11 or in xbindkeys. I have also filed a bug in xbindkeys (see: https://savannah.nongnu.org/bugs/index.php?31768) I have attached a backtrace of running `xbindkeys -n` followed by two keypresses. I have also run valgrind with xbindkeys which mysteriously prevents the crash from occurring.
Created attachment 40761 [details] the valgrind log with xbindkeys
From the first attachment: ======= Backtrace: ========= /lib/libc.so.6(+0x6c301)[0xb75ce301] /lib/libc.so.6(+0x6ee78)[0xb75d0e78] /lib/libc.so.6(__libc_malloc+0x63)[0xb75d2933] /usr/lib/libxcb.so.1(+0x9459)[0xb7552459] /usr/lib/libxcb.so.1(+0x740d)[0xb755040d] /usr/lib/libxcb.so.1(xcb_wait_for_reply+0xf7)[0xb7551cc7] /usr/lib/libX11.so.6(_XReply+0x108)[0xb77daaa8] /usr/lib/libX11.so.6(_XGetWindowAttributes+0xc8)[0xb77c07d8] /usr/lib/libX11.so.6(XGetWindowAttributes+0x42)[0xb77c0952] so cc'ing xcb list to bring it to their attention.
The stack trace does include xcb, but the crash happens inside malloc(). That usually suggests a heap smash somewhere else in the app, and not in the immediate stack trace. Any of the below from the valgrind trace could be the cause. I suggest fixing these in xbindkeys first. (The only one potentially benign is the conditional jump depending on an uninitialized value, if the results of the compare are guaranteed to be thrown away, as in zlib. I would suggest, however, that most people aren't as smart as Mark Adler and shouldn't try to outwit the computer in this fashion.) ==5777== Conditional jump or move depends on uninitialised value(s) ==5777== at 0x80498E2: ??? (in /usr/bin/xbindkeys) ==5777== by 0x41C1D25: invoke_main_func (in /usr/lib/libguile.so.17.3.1) ==5777== Invalid write of size 1 ==5777== at 0x40251BD: strncat (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==5777== by 0x8049627: ??? (in /usr/bin/xbindkeys) ==5777== by 0x8049BD9: ??? (in /usr/bin/xbindkeys) ==5777== by 0x41C1D25: invoke_main_func (in /usr/lib/libguile.so.17.3.1) ==5777== Invalid write of size 1 ==5777== at 0x40251CB: strncat (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==5777== by 0x8049627: ??? (in /usr/bin/xbindkeys) ==5777== by 0x8049BD9: ??? (in /usr/bin/xbindkeys) ==5777== by 0x41C1D25: invoke_main_func (in /usr/lib/libguile.so.17.3.1) ==5777== Invalid read of size 1 ==5777== at 0x40270A0: putenv (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==5777== by 0x804962F: ??? (in /usr/bin/xbindkeys) ==5777== by 0x8049BD9: ??? (in /usr/bin/xbindkeys) ==5777== by 0x41C1D25: invoke_main_func (in /usr/lib/libguile.so.17.3.1) ==5785== Syscall param execve(envp[i]) points to unaddressable byte(s) ==5785== at 0x42F377F: execve (in /lib/libc-2.12.1.so) ==5785== by 0x42F3BEE: execvp (in /lib/libc-2.12.1.so) ==5785== Address 0x457e043 is 0 bytes after a block of size 11 alloc'd ==5785== at 0x4024A18: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
Looks like changing an malloc in xbindkeys solved the problem. So I'm not quite sure what changed in libx11 1.4 to change this behavior but perhaps it's not a bug? The whole story is available at the link below, where I initially filed the bug: https://bugs.archlinux.org/task/21924#comment69386
Probably just a different bit of memory being overwritten by the xbindkeys overflow then, one which is more critical to Xlib not crashing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.