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


> From: Michael Snyder <msnyder@specifix.com>
> Cc: gdb@sources.redhat.com
> Date: Sat, 10 Nov 2007 22:38:14 -0800
> 
> Making sure that I understand -- you ran emacs under gdb, 
> you set a breakpoint at abort, you hit the breakpoint -- 

The .gdbinit file in the Emacs src directory always sets a breakpoint
at `abort', because Emacs calls `abort' when it encounters a ``can't
happen'' situation.

> > >   (gdb) xbacktrace
> 
> OK, I'm not familiar with that command.  "xbacktrace"?

It's defined in Emacs's src/.gdbinint.  I reproduce it below, in case
you are interested, but 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

Stack overflow, maybe?

    define xbacktrace
      set $bt = backtrace_list
      while $bt
	xgettype (*$bt->function)
	if $type == Lisp_Symbol
	  xprintsym (*$bt->function)
	  printf " (0x%x)\n", *$bt->args
	else
	  printf "0x%x ", *$bt->function
	  if $type == Lisp_Vectorlike
	    xgetptr (*$bt->function)
	    set $size = ((struct Lisp_Vector *) $ptr)->size
	    output ($size & PVEC_FLAG) ? (enum pvec_type) ($size & PVEC_TYPE_MASK) : $size & ~gdb_array_mark_flag
	  else
	    printf "Lisp type %d", $type
	  end
	  echo \n
	end
	set $bt = $bt->next
      end
    end
    document xbacktrace
      Print a backtrace of Lisp function calls from backtrace_list.
      Set a breakpoint at Fsignal and call this to see from where
      an error was signaled.
    end


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