This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB cannot access memory after Emacs abort
Michael Snyder <msnyder@specifix.com> writes:
> On Tue, 2007-11-13 at 23:28 +0100, Stephen Berman wrote:
> > On Sun, 11 Nov 2007 21:15:55 -0800 Michael Snyder <msnyder@specifix.com> wrote:
> >
> > > On Mon, 2007-11-12 at 00:01 +0100, Stephen Berman wrote:
> > >> On Sun, 11 Nov 2007 09:44:23 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > >>
> > >> > the upshot of all this is that `bt' doesn't
> > >> > work, as shown below:
> > >> >
> > >> >> > > (gdb) bt
> > >> >> > > #0 abort () at emacs.c:431
> > >> >> > > Cannot access memory at address 0xbfd6836c
> > >> >> > > Cannot access memory at address 0x8321b6c
> > >> >
> > [...]
> > > I wonder -- after the above happens, what do you get if you
> > > type the following at the (gdb) prompt:
> > >
> > > x /i $eip
> >
> > After the abort occurs, the desktop locks up, I switch to a virtual tty
> > and kill -9 the emacs process, releasing the desktop, then type what you
> > said at the gdb prompt and get this:
> >
> > 0x80f9e56 <abort+6>: Cannot access memory at address 0x80f9e56
>
> Oh yes. I understand that now, thanks.
>
> What we need, I guess, is to get back into control of
> the gdb without killing the emacs. Otherwise it is
> kind of hard to debug this gdb problem further.
You can do that by using the power of emacs :-)
Run emacs from CVS
M-x server-start RET
M-x gdb
from this gdb start another emacs session and do whatever you need to
induce the crash (just make sure that in the second instance of emacs
you don't run `server-start')
switch to a console and run
emacsclient -t
this should connect to the first emacs instance and give you access to
gdb, you can run all the gdb commands there ...
Hope this helps.