Re: XEmacs 21.4.10 crashes with glibc 2.3.1

[Stephen J. Turnbull]

>>>>> "Wolfram" == Wolfram Gloger <address@hidden> writes:

> Wrong type argument: vectorp, #<INTERNAL OBJECT (XEmacs bug?)
>                      (symbol-value-forward type 7444) 0x40198008>
> xemacs exiting

    Wolfram> Sigh, it looks like support for glibc's / "Doug Lea"'s
    Wolfram> malloc wasn't properly merged in XEmacs.  You really want
    Wolfram> to disable mmapped chunks _only_ for allocation of Lisp
    Wolfram> Objects, i.e. where pointers become tagged.  As a
    Wolfram> workaround, I've disabled use of mmap completely in the
    Wolfram> patch below.

Thanks you very much for the review and the patch!  The patch "works"
in the sense that I can now build.

I'll run with it for a while, put it in the next release candidate,
and see how it affects XEmacs's footprint.  Probably it will go in the
next release of 21.4, safety over efficiency.  But I would appreciate
it if you could help us recover the mmap capabilities.

    Wolfram> N.B. the exact same problem should/could show up with
    Wolfram> earlier glibc releases, but maybe the allocation pattern
    Wolfram> was slightly different.

I don't understand the problem so I'm not sure what you're saying.

First, your patch also affects "portable dumper" builds which build
and (mostly) run fine.  Is this intentional?  Ie, is this a generic
problem with our allocator implementation, which "just happened" to
manifest dramatically only in unexec builds on very recent glibcs?

Second, if it's a generic problem, is it possible that it would
generate GCPRO-bug-like symptoms (ie, weird crashes in "obviously
correct" code because data that we know is correctly initialized
mysteriously changes)?  For example, we fixed a couple of GCPRO bugs
recently, but we're still seeing mysterious "illegal bytecode" crashes
(especially in Gnus), although fewer of them :-).  We're pretty sure
the bytecompiler isn't responsible for this, because we've checked the
code in memory.

Third, is there still a possible problem if we use --with-system-malloc?
Ie, we use the Doug Lea malloc from glibc, but do no mallopt tweaking.

Thanks for your help.

(BTW, I've added references to your home page, and Doug Lea's,
conveniently linked from there, to our Internals docs.  Great URL!)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.