Re: GDB cannot access memory after Emacs abort

[Michael Snyder <msnyder@specifix.com>]

Hi Stephen, 

See questions inline:

On Sun, 2007-11-11 at 00:42 +0100, Stephen Berman wrote:
> I recently experienced an abort in CVS Emacs and was unable to get a
> backtrace from GDB.  The Emacs bug causing the abort was fixed, but
> Richard Stallman responded to the lack of a backtrace with this comment:
> 
> > That could be a serious problem in GDB.  It would be good to talk
> > with GDB developers about how to investigate it.  Since the bug's
> > cause is known, they could focus on figuring out why GDB fails
> > to give a backtrace.

Out of curiosity, and because RMS seems to think it's
relevant -- what is the bug's cause?

> Here is the GDB-relevant part of my bug report about the abort (Emacs
> was built using the GTK+ toolkit):

What's your host architecture?  OS?  How is gdb configured (host-target
tuple)?

> > I attempted to debug in gdb; here's the output when the abort occurs:
> >
> >   (emacs:19177): Gtk-WARNING **: Can't set a parent on widget which has a parent
> >   
> >   
> >   Gtk-ERROR **: file gtkcontainer.c: line 2641 (gtk_container_propagate_expose): assertion failed: (child->parent == GTK_WIDGET (container))
> >   aborting...
> >   [Switching to Thread 0xb6ec66c0 (LWP 19177)]
> >   
> >   Breakpoint 1, abort () at emacs.c:431
> >   431       kill (getpid (), SIGABRT);
> >
> > At this point my desktop (I tried in KDE, GNOME and twm, same behavior
> > in all) is totally locked up, but I can switch to a virtual tty and
> > there kill emacs with SIGKILL (kill -9); SIGTERM (kill -15) does not do
> > the job. 

Making sure that I understand -- you ran emacs under gdb, 
you set a breakpoint at abort, you hit the breakpoint -- 
and your desktop is locked up?

That seems unusual -- do you have any idea of the cause?

Is it possible that emacs is in an infinite recursion
and has consumed all of virtual memory, or something
of the sort?


>  This releases the desktop, but gdb delivers no further
> > feedback:
> >
> >   (gdb) xbacktrace

OK, I'm not familiar with that command.  "xbacktrace"?

Grepping my gdb source tree for "xbacktrace" produces
no results.

> >   Cannot access memory at address 0x8321b6c

Is that a valid address for your architecture?

> >   (gdb) bt
> >   #0  abort () at emacs.c:431
> >   Cannot access memory at address 0xbfd6836c
> >   Cannot access memory at address 0x8321b6c
> >
> > Setting a break point at abort() in emacs.c makes no difference.  I
> > don't have the GTK+ source code so I cannot debug it there.
> 
> Does anyone have an idea why there was no backtrace?
> 
> Steve Berman
>