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
     }
 }
 

Reply via email to