GC leak?

[Jerry James]

On Jan 31, 2008 12:13 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 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 :-).

I'm using Marcus's GC.  I should read his paper....

> 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"
> GCPRO, either).

:-)  Too little GCPRO should get flagged by valgrind as access to
unallocated memory if the garbage collector yanks the object away when
we're still using it.  I haven't seen one of those yet, although I
can't stand to work on a valgrinded XEmacs for more than about 30
minutes at a time, and I'm no longer running the Great Gnus Bug
Detector.:-(

> #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?

Good ideas.  I'll try to get to all that in the next week.
-- 
Jerry James
http://loganjerry.googlepages.com/