Re: SIGABRT while using Emacs

[Eli Zaretskii]

> From: Alex Schroeder <alex@gnu.org>
> Date: Sun, 15 Jul 2001 18:31:22 +0200
> 
> 1. started Emacs
> 2. C-x C-f ~/elisp/gnus (this is where I have my Gnus from CVS)
> 3. M-x eshell
> 4. make (at the eshell prompt)
> 5. C-x C-f -- and Emacs disappears.  It is just gone.
> 
> Here's from my GDB session:
> 
> Program received signal SIGABRT, Aborted.
> 0x4025eac1 in __kill () from /lib/libc.so.6
> (gdb) bt
> #0  0x4025eac1 in __kill () from /lib/libc.so.6
> #1  0x80981a6 in abort () at emacs.c:282
> #2  0x8080ce4 in compute_char_face (f=0x82f5d60, w=0x82f1cd8, pos=1, 
>     region_beg=-1, region_end=-1, endptr=0xbfffe308, limit=51, mouse=0)
>     at  

`compute_char_face' calls `abort' if the window it gets in its second
argument does not display the current buffer.

> (gdb) l
> 921     Lisp_Object propname;
> 922   
> 923     /* W must display the current buffer.  We could write this function
> 924        to use the frame and buffer of W, but right now it doesn't.  */
> 925     if (XBUFFER (w->buffer) != current_buffer)
> 926       abort ();
> 927   
> 928     XSETFRAME (frame, f);
> 929   
> 930     endpos = ZV;
> 
> (gdb) p current_buffer
> $1 = (struct buffer *) 0x885a530
> (gdb) pr

This was a mistake: you shouldn't use "pr" in a crashed session.  "pr"
calls a function in the Emacs executable, which can be a bad idea
after a fatal signal, because Lisp data structures can be all messed
up.

> (gdb) xtype
> Argument to arithmetic operation not a number or boolean.
> (gdb) xbuffer current_buffer
> Argument to arithmetic operation not a number or boolean.
> 
> Does that mean current_buffer is undefined / corrupted?

Maybe, maybe not.  To be sure, you should reproduce the problem, then
display the two buffers using "xtype" and "xbuffer", not "pr".

> (gdb) xbuffer w->buffer

"xbuffer" doesn't accept any arguments, it works on the value of $$.

> And I figured that xdisp.c has probably been rewritten for Emacs 21
> anyway...  :(

Yes.  For that reason, you may wish to consider leaving this alone.  I
suspect that it's some bad interaction between Eshell and the old
redisplay code.

> (gdb) p current_buffer
> $12 = (struct buffer *) 0x885a530
> (gdb) p $12->name
> $13 = 948113452
> (gdb) xstring $13
> $14 = (struct Lisp_String *) 0x883102c
> " *Minibuf-1*"
> 
> and
> 
> (gdb) p w->buffer
> $15 = 1211075120
> (gdb) xbuffer
> $16 = (struct buffer *) 0x82f8a30
> (unsigned char (*)[1]) 0x88351a4
> (gdb) p $->name
> $17 = 948130200
> (gdb) xstring
> $18 = (struct Lisp_String *) 0x8835198
> "*eshell*"

Like I said, sounds like something that Eshell does behind Emacs's
back is invalidating the assumption on which `compute_char_face' was
based.

Thanks for working on this.