On Jan 31, 2008 12:27 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Well, most of it looks to be in Xft. Why am I not surprised.
Some of the stuff in Xft is supposed to be refcounted, but what you do
and don't have to manage explicitly is nowhere documented.
That doesn't account for everything, though. Also, I traced through
the code associated with the biggest leak, of values returned from
XftFontOpenName. In fact, I did this awhile ago and found two places
in the code where XftFontClose should have been called but wasn't. I
fixed those. The finalize methods on the font objects do call
XftFontClose, and I've looked through the Xft code and verified that
it calls free() on the memory allocated by the stacktrace shown above.
So I set xft-debug-level to 3, which should make it print finalize
messages. I got none. So why isn't finalize being called on those
font objects? This is consistent with the other backtraces I have
analyzed, where the associated finalize method should free the memory
(that's the case for the bignum-related traces, for example).
Are we taking shortcuts when XEmacs quits that would lead to pointers
to Lisp objects being lost without those objects being garbage
collected? If so, what do you think of a Lisp-visible function that
calls VALGRIND_DO_LEAK_CHECK so we can see if anything has leaked
while XEmacs is still running?
XEmacs-Beta mailing list