Bug 32072 - libx11-1.4 may cause xbindkeys to crash
Summary: libx11-1.4 may cause xbindkeys to crash
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Keywords: have-backtrace
Depends on:
Reported: 2010-12-03 01:00 UTC by clu
Modified: 2010-12-06 00:32 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

xbindkeys -n crash log (4.84 KB, text/plain)
2010-12-03 01:00 UTC, clu
no flags Details
the valgrind log with xbindkeys (52.29 KB, text/plain)
2010-12-03 01:01 UTC, clu
no flags Details

Description clu 2010-12-03 01:00:48 UTC
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.
Comment 1 clu 2010-12-03 01:01:53 UTC
Created attachment 40761 [details]
the valgrind log with xbindkeys
Comment 2 Alan Coopersmith 2010-12-03 07:20:29 UTC
From the first attachment:
======= Backtrace: =========

so cc'ing xcb list to bring it to their attention.
Comment 3 Peter Harris 2010-12-03 07:43:19 UTC
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)
Comment 4 clu 2010-12-05 12:24:25 UTC
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:

Comment 5 Alan Coopersmith 2010-12-06 00:32:17 UTC
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.