This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]