On Tue 27 Sep 2005 at 22:58:31 +0300, Nadav Har'El wrote: > I just thought of a better reason why the free/XFree mismatched might have > discovered a *false* leak. My leak detector works by changing all calls to > malloc/free/etc. to calls to __wrap_malloc etc. during the linking stage > (see the "--wrap" option of ld). These wrappers follow which memory gets > allocated, and which gets freed later. > Now, it is likely that what happened is that calls to XFree() do not change > during linking and remain calls to XFree(), and then, during *dynamic linking* > (at run time), the real free() gets called, and our allocator doesn't know > the memory it allocated got freed.
That makes sense. I agree that this is probably what happened. > So, I'm sorry about this false leak report, but I guess that it is a wise > idea to clean up the XFree/free mismatch anyway, even if it's not a real > leak. Indeed, and so it is good that it was reported. Perhaps you can teach your tool of the difference between free() and XFree() (although I don't know offhand what then the X equivalent of malloc() would be). I'm working on the HiliteImage leak, and in the mean time I came across (what looks like more leaks involving title bar buttons and related Windows, and also) the possible caching in GetImage. It looks indeed like at least there is supposed to be a cache - apparently it is used in a sloppy way. I plan to send you a fresh patch tonight or tomorrow, depending on how many leaks I seem to see in this area. > Nadav Har'El | Tuesday, Sep 27 2005, 24 Elul 5765 -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
