Re: GDB cannot access memory after Emacs abort

Michael Snyder
2007-11-11T06:46:58Z

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
>