Hello Awtul,
not being the maintainer for olwm I tried to shed shome light to it
and describe some ways to get more informations out of it.
(Even when olwm got removed from testing.)
--------
First one can install the systemd facility to collect coredumps:
apt install systemd-coredump gdb
Also installing the packages containing the debug informations for
the official debian packages can offer better backtraces.
# add sources: deb http://debug.mirrors.debian.org/debian-debug/
testing-debug main
apt-get update
apt-get install olwm-dbgsym
(See https://wiki.debian.org/AutomaticDebugPackages)
Then one can login again to produce another crash and then something
like following should be possible:
# coredumpctl list
TIME PID UID GID SIG COREFILE EXE
Fri 2017-03-10 10:53:11 CET 733 1000 1000 11 present /usr/bin/olwm
# coredumpctl gdb /usr/bin/olwm
(gdb) bt
#0 0x00007fa6d28a54c7 in XKeysymToKeycode () from
/usr/lib/x86_64-linux-gnu/libX11.so.6
#1 0x000055feaa11d803 in stringToModifier (dpy=0xab32d040, word=0x7ffd6852bafe
"Meta") at evbind.c:717
#2 0x000055feaa11da5d in parseKeySpec (syms=0x7ffd6852ba90,
specifier=<optimized out>, dpy=-1422733248) at evbind.c:821
#3 establishKeyBindings (dpy=dpy@entry=0x55feab32d040, rdb=0x55feab33c5c0) at
evbind.c:905
#4 0x000055feaa11e623 in InitBindings (dpy=0x55feab32d040) at evbind.c:1324
#5 0x000055feaa1196b9 in main (argc=<optimized out>, argv=<optimized out>) at
olwm.c:290
-------
Also live debugging it would be possible by these steps:
apt-get source olwm
apt install gdbserver
nano /usr/bin/olwm-x-window-manager
# Change following line
exec /usr/bin/olwm "$@"
# to this:
exec /usr/bin/gdbserver localhost:4567 /usr/bin/olwm "$@"
# Login in wdm (in my test I have a VM with xdm installed.)
# gdb -q
(gdb) target remote localhost:4567
(gdb) directory /home/benutzer/debian/orig/xview-3.2p1.4/clients/olwm
(gdb) cont
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77084c7 in XKeysymToKeycode () from
target:/usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0 0x00007ffff77084c7 in XKeysymToKeycode () from
target:/usr/lib/x86_64-linux-gnu/libX11.so.6
#1 0x0000555555562803 in stringToModifier (dpy=0x5579f040, word=0x7fffffffd86e
"Meta") at evbind.c:717
#2 0x0000555555562a5d in parseKeySpec (syms=0x7fffffffd800,
specifier=<optimized out>, dpy=1434054720) at evbind.c:821
#3 establishKeyBindings (dpy=dpy@entry=0x55555579f040, rdb=0x5555557ae5c0) at
evbind.c:905
#4 0x0000555555563623 in InitBindings (dpy=0x55555579f040) at evbind.c:1324
#5 0x000055555555e6b9 in main (argc=<optimized out>, argv=<optimized out>) at
olwm.c:290
(gdb) up
#1 0x0000555555562803 in stringToModifier (dpy=0x5579f040, word=0x7fffffffd86e
"Meta") at evbind.c:717
717 kc = XKeysymToKeycode(dpy, ksa->sym1);
(gdb) print dpy
$1 = (Display *) 0x5579f040
(gdb) up
#2 0x0000555555562a5d in parseKeySpec (syms=0x7fffffffd800,
specifier=<optimized out>, dpy=1434054720) at evbind.c:821
821 newmod = stringToModifier(dpy, mod_string);
(gdb) print/x dpy
$2 = 0x5579f040
(gdb) up
#3 establishKeyBindings (dpy=dpy@entry=0x55555579f040, rdb=0x5555557ae5c0) at
evbind.c:905
905 nsyms = parseKeySpec(dpy, keyspec, syms);
(gdb) print/x dpy
$3 = 0x55555579f040
-------
So here the pointer given in dpy gets truncated when given to
function parseKeySpec because the declaration misses the data type,
therefore defaulting to int.
Fixing that by following change ...
static int
parseKeySpec(dpy, specifier, syms)
+ Display *dpy;
char *specifier;
modsym *syms;
{
... still leads to another crash (related to the other bugs #855168, #852532).
-------
Adding "-Wimplicit-int" to EXTRA_CFLAGS in debian/rules would print a
warning for this, but also 1465 other places ...
Kind regards,
Bernhard
