I'm working on getting changes to the virtual workspaces pushed up and I found a bug in the recent memory management cleanups where memory is being freed twice. The attached patch against cvs should comment out the code causing the issue, but I have yet to track down what the right answer is to free memory when it should be freed, but not when it shouldn't.
The double free was actually causing a seg fault that appeared to be stomping on memory such that I was getting a non-sensical crash dump in gdb. (This is under NetBSD/i386, if it matters; it also keeps track and notifies of double-memory frees). I was able to easily trigger this after opening and closing a few xterms and quickly shifting focus into it. I could quite figure out the exact things that were triggering it beyond open/close/dealing with focus, but it seemed like if I opened a window and let it sit there for a while (20 secs?), then I wouldn't crash it by shifting focus around. I'm not going to commit this patch since it probably reintroduces a memory leak, but figured I'd share what I found. For now, the ctwm that I'm running is based on the "HEAD" of the tree but with this patch (plus changes I'm testing before commit). note that this is against the cvs repository, and 3.7 does not suffer from this. -Todd
--- add_window.c efc8288ef604525373100ce0eb1e04654bc7e6d4 +++ add_window.c 3f9659833e74eda8aebd20120b2defc3649af8d9 @@ -1764,7 +1766,15 @@ } else { XFreePixmap (dpy, tmp_win->HiliteImage->pixmap); } +#if 0 + /* + * XXX - this was being free'd twice for some reason. Commenting + * this out almost certainly introduces a memory leak, but they're + * better than core dumps. :) + */ free(tmp_win->HiliteImage); + tmp_win->HiliteImage = NULL; +#endif } }