emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDB debugger mode for Emacs in ELPA


From: Nick Roberts
Subject: Re: GDB debugger mode for Emacs in ELPA
Date: Fri, 27 Jun 2008 17:30:54 +1200

 > > > Stack trace follows:
 > > > 
 > > >      ntdll.dll!7c901230()    
 > > > >    emacs.exe!w32_abort()  Line 8194    C
 > > >      emacs.exe!r_re_alloc()  Line 1030    C
 > > >...
 > > 
 > > That looks like a problem with Emacs, not the package.  Assuming that you
 > > are using GDB, what do you get if you type xbacktrace in the console?
 > > (This is a user defined command in .gdbinit which gives a backtrace of
 > > Lisp function calls.)
 > 
 > Lisp Backtrace:
 > "tar-summarize-buffer" (0x82e794)
 > "tar-mode" (0x82e860)
 > "progn" (0x82e984)
 >...

I can see that the error occurs here (in r_re_alloc in ralloc.c):

  if (bloc == NIL_BLOC)
    abort ();

I don't know why your stack trace gives no arguments for r_re_alloc as it has
two in ralloc.c.  Is it possible that Emacs has found a different copy, i.e.
one without symbols?  

Going up one frame:

#if defined USE_MMAP_FOR_BUFFERS
  p = mmap_realloc ((POINTER_TYPE **) &b->text->beg, nbytes);
#elif defined REL_ALLOC
  p = r_re_alloc ((POINTER_TYPE **) &b->text->beg, nbytes);
#else
  p = xrealloc (b->text->beg, nbytes);

Just guessing, but should REL_ALLOC be defined if you built using VS 2003?
(as that seems to imply GNU malloc).

What happened with your MinGW build?

-- 
Nick                                           http://www.inet.net.nz/~nickrob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]