Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!montnaro From: montnaro@spyder.crd.ge.com (Skip Montanaro) Newsgroups: comp.windows.x Subject: XSync(), XFlush(), and malloc() Message-ID: Date: 27 Aug 90 12:56:49 GMT Sender: news@crdgw1.crd.ge.com Reply-To: montanaro@crdgw1.ge.com (Skip Montanaro) Organization: GE Corporate Research & Development, Schenectady, NY Lines: 32 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)