Begin main content

Tracking my cygwin emacs debugging

Emacs 22.50.1 (cvs) seems to crash randomly under cygwin.

I am going to keep a track of my research here. First backtraces fingers the garbage collector which would explain why it is somewhat random. I am keeping track of the stacktraces and other useful verbose stuff in the previous blog entry (cygwin emacs cvs stack traces) I have had the same backtrace a number of times now.

The exit is caused by hitting the default clause of a case LispCons in alloc.c which I am now printing to stderr. I know nothing about cygwin api's, but here goes nothing!

Update: my c is rustier than an outback dunny! case is the match point of the switch construct (I was thinking the other way around) so my stderr print was silly! Of course since the breakpoint hits before the process exits I was able to just walk one level back up the stack and use pr to dump the lisp object. (If you're trying to debug emacs, make sure you at least browse etc/DEBUG in the emacs source). The problem is that the lisp datatype checker has no idea what it is:

(gdb) pr obj
#<EMACS BUG: INVALID DATATYPE (0x07) Save your buffers immediately and please report this bug>

So it's no wonder the garbage collector is having trouble.

Update: gdb + google = easy debugging! It seems to be the same problem as this thread:
and this one:

Update: well none of the threads I found helped me any, they are all inconclusive... Since it's *just* garbage collection, I can run crash free by just eliminating the abort, but that leads to a super phat memory leak. Open 20 frames and you've use 88Mb. Close 19 of them and you are still using 88 Mb!

Update: Seems ok in normal usage (and with plenty of VM to soak up the objects where garbage collection fails) but I would really like to get this bug fixed as I will be using emacs on cygwin for some time.

Update: Bug is still there as of 2006-12-15. See this entry for a current patch.

08:35 PM, 01 Dec 2005 by Mark Aufflick Permalink

Add comment