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 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