Jerry James writes:
Are we taking shortcuts when XEmacs quits that would lead to
to Lisp objects being lost without those objects being garbage
I don't have an opinion, bang on Marcus's door. Which GC are you
using? If it's Marcus's (I hope so, pretty clearly that's the Way of
the Future), then internal GC problems of various shapes and sizes are
quite credible (no offense to Marcus, just that AIUI inventing a
reliable GC is an incredibly hard problem, and I don't understand his
paper well enough -- ie, not at all -- to see a correctness proof :-).
However, I have a reason for singling out Xft. First, like most X11
code, the documentation about this stuff sucks (you're supposed to
know The X11 Way by heart), and there are few checks to make sure that
the callers know what they're doing. Second, I don't trust any of the
people who did a lot of work on Xft (me, Aidan, Eric Knauel) to get
GCPROs right, and we are seeing a lot more crashes that could be wild
pointers (Thomas Mittelstaed's travails on AIX for example) recently.
GCPRO problems could easily go back to 2002 and Ben's Great Mule
Merge, as only recently have lots of users been switching to 21.5 for
decent Unicode support. I do trust ben to get it 99.9% right, but I
bet he touched 2000 GCPROs in that process. I'd be surprised if he
left less than 1 GCPRO bug behind :-) (and I don't mean "too much"
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?
#ifdef DEBUG_XEMACS it and it has my vote, no matter how cheesy. :-)
Better yet, make it non-cheesy and always available. If valgrind
still requires special compilation like it used to, add a 'valgrind
feature and appropriate checks.
Then how about a valgrind Make target that would do "make check" but
with valgrind watching?
XEmacs-Beta mailing list