Catching up on this bug, which has hit some other users I know now as well.
Christian Neukirchen <chneukirc...@gmail.com> writes:
>> I found this key sequence to crash cwm on Linux in CVS HEAD:
>>
>> Minimal .cwmrc:
>> bind C-i grouponly2
>> bind CS-i movetogroup2
>>
>> Run cwm, open a window (say xterm), press C-i, press CS-i, press C-i.
>> cwm crashes on Linux with this backtrace:
>>
>> #0 0x00007ffff6027595 in raise () from /lib/libc.so.6
>> #1 0x00007ffff6028a16 in abort () from /lib/libc.so.6
>> #2 0x00007ffff60612cb in ?? () from /lib/libc.so.6
>> #3 0x00007ffff6066676 in ?? () from /lib/libc.so.6
>> #4 0x0000000000408a72 in group_show (sc=0x625d80, gc=0x625f38) at
>> group.c:135
>> #5 0x0000000000408e76 in group_only (sc=0x625d80, idx=4) at group.c:302
>> #6 0x00000000004084e7 in xev_handle_keypress (ee=0x7fffffffde00)
>> at xevents.c:335
>> #7 0x00000000004087dd in xev_loop () at xevents.c:446
>> #8 0x0000000000403969 in main (argc=<value optimized out>,
>> argv=<value optimized out>) at calmwm.c:92
>>
>
> Analyzing group_show, I found out:
>
> winlist = (Window *) xcalloc(sizeof(*winlist), (gc->highstack + 1));
> ...
> TAILQ_FOREACH(cc, &gc->clients, group_entry) {
> winlist[gc->highstack - cc->stackingorder] = cc->win;
> client_unhide(cc);
> }
>
> For some reason cc->stackingorder is bigger than gc->highstack (which is
> 0 in above use case), thus the assignment writes to a negative address
> relative to winlist. I can reproduce that on OpenBSD 4.8/cwm HEAD as
> well, it just doesn't crash there because the heap corruption goes
> undetected.
>
> I hope this helps debugging, I don't fully understand the code yet.
Breakpoint 1, group_show (sc=0x624e70, gc=0x624f98) at group.c:118
118 winlist[gc->highstack - cc->stackingorder] = cc->win;
(gdb) p gc->highstack
$5 = 0
(gdb) p cc->stackingorder
$6 = 1
--
Christian Neukirchen <chneukirc...@gmail.com> http://chneukirchen.org
