[I think my messages are getting out now.]
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org:
> [Ok, ignore all my previous ramblings....I checked FSF 20.3's source now.]
> Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
>> Yes, and therefore XEmacs uses glibc 2.x's implementation of it instead
>> of using its own. That is different in FSF Emacs isn't it?
What is different from FSF Emacs is that XEmacs allows usage of mmap
for allocation *after* dump. I checked the FSF Emacs source very
carefully and the version I looked at had it always disabled, by
When mmap is used for allocation with the Doug Lea malloc, the
addresses returned can conflict with Emacs tag bits in the high-bits
range of the address, hence ...
> So FSF does use the glibc allocator. However Steve forced XEmacs
> minimal tag bit support to on when using the Doug lea allocator. I
> cannot remember why.
Because the tag bits stomp on part of the return address pointer *when
mmap for allocation is enabled*. FSF Emacs has to turn mmap off
because they don't have the option of minimal tag bits.
> FSF Emacs doesn't have minimal tag bit support doesn't it? That
> could be the difference but it seems to me now to be more pure luck.
It was not luck, except the fortunate circumstance that Kyle
implemented it around the time I ready was to use it.
> (XEmacs also doesn't free the malloc_state_ptr but surely that cannot
> be it.
Is that a problem? We don't free *anything* starting just before
exit(3) is called (the voodoo_free_hook hack). This is due to the way
egcs/gcc-2.9 has unconditional support for constructors &
destructors. Bypassing free(3) at exit(3) time unconditionally also
bypasses all destructor calls.
I made a test on Demeter last night before she died, and I could not
reproduce the exit(3) crash described above, but that may be due to
differences between glibc-2.1 and glibc-2.0.7preX, or something else.
I have upgraded practically everything between March of 1998 and now.
I protest the NATO war in Yugoslavia.