I took another look at this GC crash. Didn't get far at all, but I
found a work around that I thought I'd log for the record.
I can repeat the problem under the latest CVS source.
Jan Vroonhof writes on 30 January:
<snip>
3. Just before executing the command that triggers the crash break
into the debugger and set the global variable always_gc=1.
<snip>
XEmacs will hopefull crash more predictably now & closer to the
real point. Try to get C & lisp back traces.
Due to a cygwin gdb issue I never managed to set always_gc=1 so, to
mix metaphors, this recipe didn't bear fruit.
I'm also not sure that always_gc would help. Looking at the stack
trace, its huge (>30K frames). My simple thinking is that some
temporary structure that VM creates when loading a folder causes the
GC loop in such away that the stack exceeds the space available or
some processor limit.
I've discovered that I can work around the crash by setting
gc-cons-threshold real high. Since I have 512M on my machine, I'm
happy with this as a work around.
BTW I have a _huge_ (44M) VM folder which is a dump from a public
newsgroup, so if anyone with more brains and bandwidth than me is
interested looking into this, get in touch.
- Phil