[Top][All Lists]
[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