I'm facing another bug in ion3:
This is probably due to my management of transcient window with a
layer 2 WFloatWS.
Steps to reproduce:
* use detach.lua and it's detach.manage_transcient_with_float hook
setup.
* Create a WFloatWS
* Open gnome-terminal, click Edit -> Current profile -> Effects
* Click "Browse"
On my machine (Debian testing), this freezes ion3. (top shows that
it's taking 100% CPU)
gdb says:
0x402c9915 in floatws_map (ws=0x81077e8) at floatws.c:158
158 if(!st->sticky || REGION_MANAGER(st->reg)==(WRegion*)ws)
(gdb) n
157 for(st=stacking; st!=NULL; st=st->next){
(gdb)
158 if(!st->sticky || REGION_MANAGER(st->reg)==(WRegion*)ws)
(gdb)
157 for(st=stacking; st!=NULL; st=st->next){
(gdb)
158 if(!st->sticky || REGION_MANAGER(st->reg)==(WRegion*)ws)
(gdb)
157 for(st=stacking; st!=NULL; st=st->next){
(gdb)
158 if(!st->sticky || REGION_MANAGER(st->reg)==(WRegion*)ws)
(gdb)
157 for(st=stacking; st!=NULL; st=st->next){
(gdb)
158 if(!st->sticky || REGION_MANAGER(st->reg)==(WRegion*)ws)
(gdb)
157 for(st=stacking; st!=NULL; st=st->next){
(gdb)
158 if(!st->sticky || REGION_MANAGER(st->reg)==(WRegion*)ws)
(gdb) list
153 {
154 WFloatStacking *st;
155 WFloatWS *ws2;
156
157 for(st=stacking; st!=NULL; st=st->next){
158 if(!st->sticky || REGION_MANAGER(st->reg)==(WRegion*)ws)
159 continue;
160
161 ws2=same_stacking(ws, st->reg);
162
Valgrind says
==18755== Memcheck, a memory error detector for x86-linux.
==18755== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==18755== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==18755== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==18755== For more details, rerun with: -v
==18755==
==18755== Syscall param writev(vector[...]) contains uninitialised or
unaddressable byte(s)
==18755== at 0x1BAFD71E: (within /lib/libc-2.3.2.so)
==18755== by 0x1B97FE8F: (within /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x1B980A5E: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x1B961176: _XSend (in /usr/X11R6/lib/libX11.so.6.2)
==18755== Address 0x1BB937B5 is 77 bytes inside a block of size 2048 alloc'd
==18755== at 0x1B907901: calloc (vg_replace_malloc.c:176)
==18755== by 0x1B95209C: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x80581C5: ioncore_startup (ioncore.c:381)
==18755== by 0x8056D7C: main (ion.c:244)
==18755==
==18755== Syscall param write(buf) contains uninitialised or unaddressable
byte(s)
==18755== at 0x1BAF6BC8: write (in /lib/libc-2.3.2.so)
==18755== by 0x1B9809FE: _X11TransWrite (in /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x1B960261: (within /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x1B96190C: _XReply (in /usr/X11R6/lib/libX11.so.6.2)
==18755== Address 0x1BB93776 is 14 bytes inside a block of size 2048 alloc'd
==18755== at 0x1B907901: calloc (vg_replace_malloc.c:176)
==18755== by 0x1B95209C: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x80581C5: ioncore_startup (ioncore.c:381)
==18755== by 0x8056D7C: main (ion.c:244)
==18755==
==18755== Syscall param write(buf) contains uninitialised or unaddressable
byte(s)
==18755== at 0x1BAF6BC8: write (in /lib/libc-2.3.2.so)
==18755== by 0x1B9809FE: _X11TransWrite (in /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x1B960261: (within /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x1B9600E6: _XFlush (in /usr/X11R6/lib/libX11.so.6.2)
==18755== Address 0x1BB93791 is 41 bytes inside a block of size 2048 alloc'd
==18755== at 0x1B907901: calloc (vg_replace_malloc.c:176)
==18755== by 0x1B95209C: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==18755== by 0x80581C5: ioncore_startup (ioncore.c:381)
==18755== by 0x8056D7C: main (ion.c:244)
/home/moy/local/usr/bin/ion3: Caught signal 2. Dying.
==18755==
==18755== ERROR SUMMARY: 39 errors from 3 contexts (suppressed: 59 from 1)
==18755== malloc/free: in use at exit: 582675 bytes in 13341 blocks.
==18755== malloc/free: 36563 allocs, 23222 frees, 1752143 bytes allocated.
==18755== For a detailed leak analysis, rerun with: --leak-check=yes
==18755== For counts of detected errors, rerun with: -v
(More generally, I find ion really unstable when using layer 2
WFloatWS. I think it needs more testing)
(And by the way, I'm mainly talking about ion's bugs here, but Ion 3
is really great. Thanks Tuomo !)
--
Matthieu
