Re: C-g crash redux

[Richard Stallman <rms@gnu.org>]

    | #6  0x08124fd4 in abort () at emacs.c:464
    | #7  0x081e70fd in Fbyte_code (bytestr=136529099, vector=136529116, maxdepth=40)
    |     at bytecode.c:1666
    | #8  0x081ad855 in funcall_lambda (fun=136529036, nargs=1, 
    |     arg_vector=0xafda15a4) at eval.c:3169
    | #9  0x081ad315 in Ffuncall (nargs=2, args=0xafda15a0) at eval.c:3028

Please do

f 9
p *args
xpr

so we can see what Lisp function is running.

If you run with a breakpoint at abort, then you will catch this
before it really tries to kill itself.  Then you will be able
to use the GDB command `pr' to print Lisp objects nicely.

.gdbinit in the Emacs source directory normally puts a breakpoint at
abort.  Why don't you have one?  Did you somehow avoid running .gdbinit?

Anyway, the next step after we know which function
is to try disassembling it and see how it could fail to clear
its specpdl entries.  Maybe it was compiled incorrectly;
someone should study its bytecode to see that it really
corresponds to the Lisp code and is consistent.