This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
GDB cannot access memory after Emacs abort
- From: Stephen Berman <Stephen dot Berman at gmx dot net>
- To: gdb at sources dot redhat dot com
- Date: Sun, 11 Nov 2007 00:42:33 +0100
- Subject: GDB cannot access memory after Emacs abort
- References: <87r6j6rvn3.fsf@escher.local.home>
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.
Here is the GDB-relevant part of my bug report about the abort (Emacs
was built using the GTK+ toolkit):
> 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. This releases the desktop, but gdb delivers no further
> feedback:
>
> (gdb) xbacktrace
> Cannot access memory at address 0x8321b6c
> (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