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 Tue, 13 Nov 2007 15:05:36 -0800 Michael Snyder <msnyder@specifix.com> wrote:

> On Tue, 2007-11-13 at 23:28 +0100, Stephen Berman wrote:
[...]
>> Note, however, that this only happens when running emacs under gdb; if I
>> start emacs directly from the shell, induce the abort, then the Emacs
>> window vanishes, but the desktop remains responsive and no other
>> problems are apparent.
>
> Well that's understandable.  emacs has grabbed the focus, presumably
> something you are only supposed to do for a brief interval.  If emacs
> aborts, it will let go of the focus when it dies, but if gdb stops it
> from dying, it can't let go of the focus.
>
> This would happen with any resource that a debugged program 
> had a lock on.  You can create deadlocks when you debug things
> that have locks on resources.
>
> That's a fact of life.

Ok, I understand this now.

>> > Am I correct in understanding that:
>> > - your X session locks up, and all your windows are unresponsive, not
>> >   just GDB's and Emacs
>> 
>> Yes, all open X apps are unresponsive to keyboard or mouse input, but
>> the apps continue to operate normally, e.g., the newsticker scrolls, the
>> displays in gkrellm (time, CPU activity, free memory, etc.) continue to
>> be updated.
>
> I would prefer if we could set this issue aside.
> I don't believe it is a gdb issue.  The backtrace
> issue is what we should discuss.

See my followup to your suggestion to attach the emacs process to gdb.

Steve Berman


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