Re: Memory corruption errors!?

sjt> That's right. There are in fact four fairly well-defined subtasks: Nice summary, thanks! sjt> 1) Regularizing the memory layouts and providing them with sjt> descriptions that various subsystems can interpret. This doesn't sjt> really have its own option or #ifdef macro AIUI. This required sjt> for the MC_ALLOC and NEWGC tasks. And it is required for the portable dumper. It introduced the descriptions. sjt> 2) Changing the mark algorithm to be more modular, to allow sjt> allocation and GC algorithms to be changed more easily. This is sjt> the KKCC part. The mark algorithm uses an explicit stack that keeps track of the current progress of traversal, instead of the recursion that mark_object uses. sjt> 3) Changing and generalizing the Lisp allocator, to cooperate with sjt> various mark and GC algorithms and regularize internal memory sjt> allocation. Although there have been some growing pains, this sjt> should eventually help us capture almost all XEmacs internal sjt> allocation in the memory usage statistics. (We'll still face the sjt> issue that X11 and various image and font libraries do their own sjt> internal allocation, so XEmacs-reported memory size will always be sjt> substantially smaller than VSIZE in ps.) This is denoted MC_ALLOC. I wouldn't stress the memory usage statistics, which is a by-product IMO. The real benefit, as Stephen mentions correctly, is the regularized internal memory allocation. sjt> 4) Changing the GC algorithm itself. This was called NEWGC, but in sjt> fact technically it's very hard to disentangle from the allocator, sjt> so Marcus put this under control of MC_ALLOC in the source code. Stephen mixed this up: I removed MC_ALLOC and put it under control of NEWGC. sjt> Thus now there are changes that don't depend on any of the switches, sjt> mark algorithm changes that depend on --with-kkcc (on by default) and sjt> allocation and gc algorithm changes that depend on --with-mc-alloc. To enable the new allocator and the new incremental garbage collector, you have to use --enable-newgc. The configuration option --enable-mc-alloc is gone. sjt> Not as clean as you might like, but there are limits to how much sjt> backward compatibility you can preserve with this kind of refactoring. The new allocator has certain features like allocation of Lisp arrays that the old allocator doesn't have. sjt> I believe there are debugging techniques that GCC can enable without sjt> much external support, but I don't know much about them. You could sjt> also run with valgrind, which is known to be very effective for this sjt> kind of debugging. I recommend to use valgrind, it should find this bug. Then, you can attach a debugger and get a backtrace. -- Marcus