montnaro@spyder.crd.ge.com (Skip Montanaro) (08/27/90)
I'm trying to track down some memory leaks in a program of ours. As a first
check, in gdb I set breakpoints in malloc() and free(), with actions to
print a short backtrace and then continue. Not surprisingly, I count more
malloc()s than free()s. What is a bit surprising is the following two
backtraces that occur frequently:
#0 0x274164 in malloc ()
#1 0x25b938 in _XEnq ()
#2 0x25b898 in _XReply ()
#3 0x2594d0 in XSync ()
(More stack frames follow...)
#0 0x274164 in malloc ()
#1 0x25b938 in _XEnq ()
#2 0x24b1d4 in _XWaitForWritable ()
#3 0x25aeb0 in _XFlush ()
(More stack frames follow...)
As far as I can tell, there are no matching backtraces that call free(). In
fact, the only free() calls I saw connected with Xlib were during
XOpenDisplay() or XSetStandardProperties(), very early on during execution.
Those all appeared to match immediately preceeding malloc() or calloc()
calls.
I know absolutely nothing about Xlib internals. Is there some kind soul who
can explain where _XEnq()'s mallocated storage is freed, if at all?
Thx,
--
Skip (montanaro@crdgw1.ge.com)rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (08/27/90)
Is there some kind soul who
can explain where _XEnq()'s mallocated storage is freed, if at all?
Xlib maintains a global (not per display) free list of event queue elements.
They are never freed, not even at display close. I guess the assumption is
that the free list would never get very large. If you want to consider this
a bug, you are welcome to submit a bug report, but in that case please provide
a suggested effecient alternate implementation strategy, and explain why the
current implementation causes a real problem in your application.