This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB cannot access memory after Emacs abort
- From: Michael Snyder <msnyder at specifix dot com>
- To: Stephen Berman <Stephen dot Berman at gmx dot net>
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 10 Nov 2007 22:38:14 -0800
- Subject: Re: GDB cannot access memory after Emacs abort
- References: <87r6j6rvn3.fsf@escher.local.home> <87hcjtllau.fsf@escher.local.home>
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
>