Re: Memory corruption errors!?

Mats> Adrian Aichner writes: That's correct. It's not yet enabled by default. Mats> OK. I though that "Using the new GC mark algorithms (KKCC)." Mats> was just that but then again it might just be the "new GC Mats> mark algorithms" which probably is something completely Mats> different. That's right. There are in fact four fairly well-defined subtasks: 1) Regularizing the memory layouts and providing them with descriptions that various subsystems can interpret. This doesn't really have its own option or #ifdef macro AIUI. This required for the MC_ALLOC and NEWGC tasks. 2) Changing the mark algorithm to be more modular, to allow allocation and GC algorithms to be changed more easily. This is the KKCC part. 3) Changing and generalizing the Lisp allocator, to cooperate with various mark and GC algorithms and regularize internal memory allocation. Although there have been some growing pains, this should eventually help us capture almost all XEmacs internal allocation in the memory usage statistics. (We'll still face the issue that X11 and various image and font libraries do their own internal allocation, so XEmacs-reported memory size will always be substantially smaller than VSIZE in ps.) This is denoted MC_ALLOC. 4) Changing the GC algorithm itself. This was called NEWGC, but in fact technically it's very hard to disentangle from the allocator, so Marcus put this under control of MC_ALLOC in the source code. Thus now there are changes that don't depend on any of the switches, mark algorithm changes that depend on --with-kkcc (on by default) and allocation and gc algorithm changes that depend on --with-mc-alloc. Not as clean as you might like, but there are limits to how much backward compatibility you can preserve with this kind of refactoring. Mats> Thanks. I might do that but then, if I'm not using the new Mats> GC, the problem is more alarming because it then seems like Mats> something old is broken. This is quite likely, since the whole effort is a refactoring. Mats> Let me try again. I have a stack trace. I just want to know Mats> whether it can be useful when it comes to these "Memory Mats> corruption errors". I believe there are debugging techniques that GCC can enable without much external support, but I don't know much about them. You could also run with valgrind, which is known to be very effective for this kind of debugging. All of the above should be considered interim discussion until Marcus has time to weigh in with accurate information, but that should give you a feel for what's going on. HTH! -- School of Systems and Information Engineering 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.