This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB cannot access memory after Emacs abort
On Sat, 10 Nov 2007 22:38:14 -0800 Michael Snyder <msnyder@specifix.com> wrote:
> 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?
It had to do with the handling of named icons in GTK+ tool bars. I
don't know the code well enough to say more, but the diff is here:
http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/gtkutil.c?r1=1.120&r2=1.121&pathrev=MAIN
>> 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)?
Linux escher 2.6.22.12-0.1-default i686 athlon i386 GNU/Linux (openSUSE
10.3)
GNU gdb 6.6.50.20070726-cvs
This GDB was configured as "i586-suse-linux".
> 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?
Yes (as Eli Zaretskii pointed out, Emacs set a breakpoint at abort).
> That seems unusual -- do you have any idea of the cause?
No! I'm hoping someone here might have some insight.
> Is it possible that emacs is in an infinite recursion
> and has consumed all of virtual memory, or something
> of the sort?
This has happened on (rare) occasion, but it never locked up the
desktop, I could always at least kill -9 the emacs process from within
the X window system (in the case under discussion, I was able to switch
to a virtual tty and kill -9 the emacs process from there, but X was
locked up solid).
>> > Cannot access memory at address 0x8321b6c
>
> Is that a valid address for your architecture?
How can I determine that?
Anyway, it sound like you don't suspect a bug in GDB that prevented
getting a backtrace, or is that still a possibility?
Steve Berman