Re: XEmacs 21.4.10 crashes with glibc 2.3.1

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.