* GDB debugger mode for Emacs in ELPA
@ 2008-06-26 1:03 Nick Roberts
0 siblings, 0 replies; 8+ messages in thread
From: Nick Roberts @ 2008-06-26 1:03 UTC (permalink / raw)
To: emacs-devel
I have updated the GDB debugger mode in the Emacs Lisp Package Archive at
http://tromey.com/elpa (couretesy of Tom Tromey). This is much improved and
now provides a good basis for future inclusion in Emacs.
It comprises of modified gud.el and a file called gdb-mi.el which replaces
gdb-ui.el. When installed, this overrides the current files and invoking M-x
gdb will use GDB/MI directly (starts with "gdb -i=mi"). When deleted ('d'
followed by 'x' in Package Menu mode), the files are deleted and old
functionality restored.
It would be helpful if others could test/develop it.
Here's some background for those who are interested
The file gdb-ui.el uses an interface for GDB called annotations. This involves
marking up GDB's output, which is really intended to be read by humans. This
output changes with time and has variable formatting, so a more stable and
precise machine interface called GDB/MI is being developed. In future some
features of GDB will only be available through GDB/MI so it is essential that
Emacs migrates to it.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB debugger mode for Emacs in ELPA
@ 2008-06-26 3:45 filerz-emacs
2008-06-26 4:11 ` Nick Roberts
0 siblings, 1 reply; 8+ messages in thread
From: filerz-emacs @ 2008-06-26 3:45 UTC (permalink / raw)
To: Nick Roberts, emacs-devel
Hello,
----- Original Message ----
> From: Nick Roberts <nickrob@snap.net.nz>
> To: emacs-devel@gnu.org
> Sent: Thursday, 26 June, 2008 6:33:01 AM
> Subject: GDB debugger mode for Emacs in ELPA
>
>
> It would be helpful if others could test/develop it.
I started off the process of installing ELPA, it was real nice and simple. I then tried installing gdb-mi package started getting a repeatable crash in emacs. The crash is happening in some ralloc.c. The initial downloading works, I feel it is in extracting the archive and manipulating it in emacs that is causing the problem. Let me try the same with a MinGW build.
I am using Emacs from GIT HEAD on M$-XP build using VS 2003 with image support.
Stack trace follows:
ntdll.dll!7c901230()
> emacs.exe!w32_abort() Line 8194 C
emacs.exe!r_re_alloc() Line 1030 C
emacs.exe!enlarge_buffer_text(buffer * b=0x015c3400, int delta=2199) Line 5051 + 0x9 C
emacs.exe!make_gap_larger() Line 529 C
emacs.exe!make_gap(int nbytes_added=199) Line 623 C
emacs.exe!insert_from_string_1(int string=1630546000, int pos=0, int pos_byte=0, int nchars=219, int nbytes=219, int inherit=0, int before_markers=0) Line 1107 + 0xa C
emacs.exe!insert_from_string(int string=1630546000, int pos=0, int pos_byte=0, int length=219, int length_byte=219, int inherit=0) Line 1050 C
emacs.exe!general_insert_function(void (const unsigned char *, int)* insert_func=0x010beb2c, void (int, int, int, int, int, int)* insert_from_string_func=0x010bed58, int inherit=0, int nargs=2, int * args=0x0082ec5c) Line 2183 + 0x1f C
emacs.exe!Finsert(int nargs=2, int * args=0x0082ec5c) Line 2225 C
emacs.exe!Fbyte_code(int bytestr=26195720, int vector=-2121287936, int maxdepth=6) Line 1267 C
emacs.exe!funcall_lambda(int fun=-2120005600, int nargs=0, int * arg_vector=0x0082ed30) Line 3231 + 0xe C
emacs.exe!Ffuncall(int nargs=0, int * args=0x217d5f00) Line 3088 + 0xc C
emacs.exe!Fbyte_code(int bytestr=27412488, int vector=-2120071168, int maxdepth=5) Line 680 C
emacs.exe!funcall_lambda(int fun=-2120131232, int nargs=0, int * arg_vector=0x0082edb4) Line 3231 + 0xe C
emacs.exe!apply_lambda(int fun=-2120131232, int args=556704768, int eval_flag=1) Line 3156 C
emacs.exe!Feval(int form=-1576242512) Line 2415 + 0xb C
emacs.exe!Fprogn(int args=-1576242504) Line 450 C
emacs.exe!Feval(int form=-1576242504) Line 2374 C
emacs.exe!Fif(int args=-1576242320) Line 397 + 0x16 C
emacs.exe!Feval(int form=-1576242320) Line 2374 C
emacs.exe!Fprogn(int args=-1576241776) Line 450 C
emacs.exe!funcall_lambda(int fun=-1576244032, int nargs=0, int * arg_vector=0x0082ef70) Line 3222 + 0xf C
emacs.exe!apply_lambda(int fun=-1576244032, int args=556704768, int eval_flag=1) Line 3156 C
emacs.exe!Feval(int form=-1576246440) Line 2415 + 0xb C
emacs.exe!Fprogn(int args=-1576246480) Line 450 C
emacs.exe!FletX(int args=-1576246432) Line 1034 C
emacs.exe!Feval(int form=-1576246432) Line 2374 C
emacs.exe!Fprogn(int args=-1576245400) Line 450 C
emacs.exe!Flet(int args=-1576245368) Line 1090 C
emacs.exe!Feval(int form=-1576245368) Line 2374 C
emacs.exe!Fprogn(int args=-1576246992) Line 450 C
emacs.exe!funcall_lambda(int fun=-1576247008, int nargs=2, int * arg_vector=0x0082f174) Line 3222 + 0xf C
emacs.exe!apply_lambda(int fun=-1576247008, int args=556704768, int eval_flag=1) Line 3156 C
emacs.exe!Feval(int form=-1576228544) Line 2415 + 0xb C
emacs.exe!Fprogn(int args=-1576228392) Line 450 C
emacs.exe!Fsave_excursion(int args=-1576228392) Line 1004 C
emacs.exe!Feval(int form=-1576228392) Line 2374 C
emacs.exe!Fprogn(int args=-1576228608) Line 450 C
emacs.exe!Flet(int args=-1576228344) Line 1090 C
emacs.exe!Feval(int form=-1576228344) Line 2374 C
emacs.exe!Fprogn(int args=-1576226088) Line 450 C
emacs.exe!funcall_lambda(int fun=-1576228624, int nargs=2, int * arg_vector=0x0082f380) Line 3222 + 0xf C
emacs.exe!apply_lambda(int fun=-1576228624, int args=556704768, int eval_flag=1) Line 3156 C
emacs.exe!Feval(int form=-1576169376) Line 2415 + 0xb C
emacs.exe!Fprogn(int args=-1576169440) Line 450 C
emacs.exe!Fcond(int args=-1576169448) Line 426 + 0x6 C
emacs.exe!Feval(int form=-1576169448) Line 2374 C
emacs.exe!Fprogn(int args=-1576170856) Line 450 C
emacs.exe!FletX(int args=-1576169088) Line 1034 C
emacs.exe!Feval(int form=-1576169088) Line 2374 C
emacs.exe!Fprogn(int args=-1575967544) Line 450 C
emacs.exe!funcall_lambda(int fun=-1575967560, int nargs=1, int * arg_vector=0x0082f5c0) Line 3222 + 0xf C
emacs.exe!Ffuncall(int nargs=1, int * args=0xa210a4b8) Line 3088 + 0xc C
emacs.exe!call1(int fn=-1575967560, int arg1=561570368) Line 2823 + 0xb C
emacs.exe!mapcar1() Line 2473 + 0xc C
emacs.exe!Fmapc(int function=-1575967560, int sequence=-1575967536) Line 2565 + 0xd C
emacs.exe!Feval(int form=556704768) Line 2377 C
emacs.exe!Fprogn(int args=-1576168328) Line 450 C
emacs.exe!funcall_lambda(int fun=-1576170952, int nargs=1, int * arg_vector=0x0082f6c0) Line 3222 + 0xf C
emacs.exe!apply_lambda(int fun=-1576170952, int args=556704768, int eval_flag=1) Line 3156 C
emacs.exe!Feval(int form=-1576172688) Line 2415 + 0xb C
emacs.exe!Fprogn(int args=-1576136576) Line 450 C
emacs.exe!Flet(int args=-1576172640) Line 1090 C
emacs.exe!Feval(int form=-1576172640) Line 2374 C
emacs.exe!Fprogn(int args=-1576172144) Line 450 C
emacs.exe!Flet(int args=-1576171816) Line 1090 C
emacs.exe!Feval(int form=-1576171816) Line 2374 C
emacs.exe!Fprogn(int args=-1576171032) Line 450 C
emacs.exe!funcall_lambda(int fun=-1576136616, int nargs=1, int * arg_vector=0x0082f948) Line 3222 + 0xf C
emacs.exe!Ffuncall(int nargs=1, int * args=0x21349a10) Line 3088 + 0xc C
emacs.exe!Fapply(int nargs=2, int * args=0x0082f944) Line 2530 + 0x9 C
emacs.exe!apply1(int fn=557095440, int arg=-1575966624) Line 2791 + 0xe C
emacs.exe!Fcall_interactively(int function=557095440, int record_flag=556704816, int keys=-1575966632) Line 389 + 0xb C
emacs.exe!Ffuncall(int nargs=3, int * args=0x21325000) Line 3050 C
emacs.exe!call3(int fn=556945408, int arg1=557095440, int arg2=556704816, int arg3=556704768) Line 2868 + 0xb C
emacs.exe!Fcommand_execute(int cmd=557095440, int record_flag=556704816, int keys=556704768, int special=556704768) Line 10434 + 0x14 C
emacs.exe!Fexecute_extended_command(int prefixarg=556704768) Line 10547 + 0xe C
emacs.exe!Ffuncall(int nargs=1, int * args=0x21303e58) Line 3043 C
emacs.exe!Fcall_interactively(int function=556809816, int record_flag=556704768, int keys=0) Line 859 C
emacs.exe!Ffuncall(int nargs=3, int * args=0x21325000) Line 3050 C
emacs.exe!call3(int fn=556945408, int arg1=556809816, int arg2=556704768, int arg3=556704768) Line 2868 + 0xb C
emacs.exe!Fcommand_execute(int cmd=556809816, int record_flag=556704768, int keys=556704768, int special=556704768) Line 10434 + 0x14 C
emacs.exe!command_loop_1() Line 1918 C
emacs.exe!internal_condition_case(int (void)* bfun=0x01062b3e, int handlers=556817624, int (void)* hfun=0x0105ebfd) Line 1512 C
emacs.exe!command_loop_2() Line 1367 + 0x15 C
emacs.exe!internal_catch(int tag=556809600, int (void)* func=0x01063ab1, int arg=556704768) Line 1247 + 0x6 C
emacs.exe!command_loop() Line 1347 C
emacs.exe!recursive_edit_1() Line 955 + 0x5 C
emacs.exe!Frecursive_edit() Line 1018 C
emacs.exe!main() Line 1772 + 0x5 C
emacs.exe!mainCRTStartup() Line 259 + 0x12 C
kernel32.dll!7c816fd7()
-dky
Bring your gang together. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo.com/groups/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB debugger mode for Emacs in ELPA
2008-06-26 3:45 filerz-emacs
@ 2008-06-26 4:11 ` Nick Roberts
0 siblings, 0 replies; 8+ messages in thread
From: Nick Roberts @ 2008-06-26 4:11 UTC (permalink / raw)
To: filerz-emacs; +Cc: emacs-devel
> I started off the process of installing ELPA, it was real nice and simple. I
> then tried installing gdb-mi package started getting a repeatable crash in
> emacs. The crash is happening in some ralloc.c. The initial downloading
> works, I feel it is in extracting the archive and manipulating it in emacs
> that is causing the problem. Let me try the same with a MinGW build.
>
> I am using Emacs from GIT HEAD on M$-XP build using VS 2003 with image
> support.
>
> 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.)
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB debugger mode for Emacs in ELPA
@ 2008-06-26 5:52 filerz-emacs
2008-06-27 5:30 ` Nick Roberts
0 siblings, 1 reply; 8+ messages in thread
From: filerz-emacs @ 2008-06-26 5:52 UTC (permalink / raw)
To: Nick Roberts; +Cc: emacs-devel
Hi,
----- Original Message ----
> From: Nick Roberts <nickrob@snap.net.nz>
> > I am using Emacs from GIT HEAD on M$-XP build using VS 2003 with image
> > support.
> >
> > 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)
"if" (0x82ea04)
"package-untar-buffer" (0x82ea80)
"let*" (0x82ebd4)
"let" (0x82ecb4)
"package-unpack" (0x82ed30)
"save-excursion" (0x82ee84)
"let" (0x82ef64)
"package-download-tar" (0x82efe0)
"cond" (0x82f114)
"let*" (0x82f1d4)
0x388401d Lisp type 5
"mapc" (0x82f360)
"package-download-transaction" (0x82f410)
"let" (0x82f594)
"let" (0x82f674)
"package-install" (0x82f794)
"call-interactively" (0x82f93c)
"execute-extended-command" (0x82fac4)
"call-interactively" (0x82fc7c)
-dky
Best Jokes, Best Friends, Best Food and more. Go to http://in.promos.yahoo.com/groups/bestofyahoo/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB debugger mode for Emacs in ELPA
2008-06-26 5:52 GDB debugger mode for Emacs in ELPA filerz-emacs
@ 2008-06-27 5:30 ` Nick Roberts
2008-06-27 9:15 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Nick Roberts @ 2008-06-27 5:30 UTC (permalink / raw)
To: filerz-emacs; +Cc: emacs-devel
> > > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB debugger mode for Emacs in ELPA
@ 2008-06-27 5:44 filerz-emacs
2008-06-27 6:09 ` Nick Roberts
0 siblings, 1 reply; 8+ messages in thread
From: filerz-emacs @ 2008-06-27 5:44 UTC (permalink / raw)
To: Nick Roberts; +Cc: emacs-devel
Hello,
----- Original Message ----
> From: Nick Roberts <nickrob@snap.net.nz>
> 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?
I have a build using optimizations (O2). I now have a build with optimizations disabled.
> Just guessing, but should REL_ALLOC be defined if you built using VS 2003?
> (as that seems to imply GNU malloc).
The backtrace was from the MinGW build (with optimizations)
> What happened with your MinGW build?
The back trace without optimizations:
(gdb) bt
#0 w32_abort () at w32fns.c:8179
#1 0x01190a28 in r_re_alloc (ptr=0x2ed8a08, size=2220) at ralloc.c:1028
#2 0x0106fd65 in enlarge_buffer_text (b=0x2ed8a00, delta=2199) at buffer.c:5051
#3 0x01146d19 in make_gap_larger (nbytes_added=2199) at insdel.c:526
#4 0x01147045 in make_gap (nbytes_added=199) at insdel.c:621
#5 0x01147c31 in insert_from_string_1 (string=53214147, pos=0, pos_byte=0, nchars=219, nbytes=219, inherit=0, before_markers=0) at insdel.c:1107
#6 0x01147ab3 in insert_from_string (string=53214147, pos=0, pos_byte=0, length=219, length_byte=219, inherit=0) at insdel.c:1048
#7 0x0113a118 in general_insert_function (insert_func=0x1147410 <insert>, insert_from_string_func=0x1147a7a <insert_from_string>, inherit=0, nargs=2, arg
#8 0x0113a179 in Finsert (nargs=2, args=0x0) at editfns.c:2224
#9 0x01118eef in Fbyte_code (bytestr=48484307, vector=50588676, maxdepth=48) at bytecode.c:1265
#10 0x010245fb in funcall_lambda (fun=51236420, nargs=0, arg_vector=0x82d654) at eval.c:3229
#11 0x010240cf in Ffuncall (nargs=1, args=0x82d650) at eval.c:3088
#12 0x011171ee in Fbyte_code (bytestr=53051635, vector=50881540, maxdepth=40) at bytecode.c:678
#13 0x010245fb in funcall_lambda (fun=51234372, nargs=0, arg_vector=0x82d8e0) at eval..c:3229
#14 0x010242e5 in apply_lambda (fun=51234372, args=43726849, eval_flag=1) at eval.c:3153
#15 0x010231c7 in Feval (form=58300885) at eval.c:2415
#16 0x01020003 in Fprogn (args=58300869) at eval.c:449
#17 0x01022df3 in Feval (form=58301085) at eval.c:2320
#18 0x0101ff1d in Fif (args=58301133) at eval.c:397
#19 0x01022df3 in Feval (form=58301269) at eval.c:2320
#20 0x01020003 in Fprogn (args=58300317) at eval.c:449
#21 0x010245ae in funcall_lambda (fun=58300309, nargs=0, arg_vector=0x82dcc0) at eval.c:3222
#22 0x010242e5 in apply_lambda (fun=58300309, args=43726849, eval_flag=1) at eval.c:3153
#23 0x010232ab in Feval (form=58297893) at eval.c:2433
#24 0x01020003 in Fprogn (args=58297877) at eval.c:449
#25 0x01020fa0 in FletX (args=58297901) at eval.c:1033
#26 0x01022df3 in Feval (form=58298165) at eval.c:2320
#27 0x01020003 in Fprogn (args=58295773) at eval.c:449
#28 0x01021204 in Flet (args=58299901) at eval.c:1089
#29 0x01022df3 in Feval (form=58300181) at eval.c:2320
#30 0x01020003 in Fprogn (args=58295765) at eval.c:449
#31 0x010245ae in funcall_lambda (fun=58295757, nargs=2, arg_vector=0x82e180) at eval.c:3222
#32 0x010242e5 in apply_lambda (fun=58295757, args=58331517, eval_flag=1) at eval.c:3153
#33 0x010232ab in Feval (form=58331525) at eval.c:2433
#34 0x01020003 in Fprogn (args=58331501) at eval.c:449
#35 0x01137947 in Fsave_excursion (args=58331621) at editfns.c:1003
#36 0x01022df3 in Feval (form=58331645) at eval.c:2320
#37 0x01020003 in Fprogn (args=58331469) at eval.c:449
#38 0x01021204 in Flet (args=58331653) at eval.c:1089
#39 0x01022df3 in Feval (form=58331765) at eval.c:2320
#40 0x01020003 in Fprogn (args=58331461) at eval.c:449
#41 0x010245ae in funcall_lambda (fun=58331453, nargs=2, arg_vector=0x82e620) at eval.c:3222
#42 0x010242e5 in apply_lambda (fun=58331453, args=58327205, eval_flag=1) at eval.c:3153
#43 0x010232ab in Feval (form=58327213) at eval.c:2433
#44 0x01020003 in Fprogn (args=58327189) at eval.c:449
#45 0x0101ffbf in Fcond (args=58327181) at eval.c:426
#46 0x01022df3 in Feval (form=58327269) at eval.c:2320
#47 0x01020003 in Fprogn (args=58326933) at eval.c:449
#48 0x01020fa0 in FletX (args=58327277) at eval.c:1033
#49 0x01022df3 in Feval (form=58327445) at eval.c:2320
#50 0x01020003 in Fprogn (args=58381413) at eval.c:449
#51 0x010245ae in funcall_lambda (fun=58381397, nargs=1, arg_vector=0x82eb44) at eval.c:3222
#52 0x01024157 in Ffuncall (nargs=2, args=0x82eb40) at eval.c:3099
#53 0x010239dc in call1 (fn=58381397, arg1=48498313) at eval.c:2823
#54 0x01098a7f in mapcar1 (leni=1, vals=0x0, fn=58381397, seq=58381421) at fns.c:2502
#55 0x01098e33 in Fmapc (function=58381397, sequence=58381421) at fns.c:2594
#56 0x01022ffa in Feval (form=58327477) at eval.c:2376
#57 0x01020003 in Fprogn (args=58326885) at eval.c:449
#58 0x010245ae in funcall_lambda (fun=58326877, nargs=1, arg_vector=0x82ed70) at eval.c:3222
#59 0x010242e5 in apply_lambda (fun=58326877, args=58326237, eval_flag=1) at eval.c:3153
#60 0x010232ab in Feval (form=58326245) at eval.c:2433
#61 0x01020003 in Fprogn (args=58326229) at eval.c:449
#62 0x01021204 in Flet (args=58326253) at eval.c:1089
#63 0x01022df3 in Feval (form=58326413) at eval.c:2320
#64 0x01020003 in Fprogn (args=58326221) at eval.c:449
#65 0x01021204 in Flet (args=58326509) at eval.c:1089
#66 0x01022df3 in Feval (form=58326565) at eval.c:2320
#67 0x01020003 in Fprogn (args=58326213) at eval.c:449
#68 0x010245ae in funcall_lambda (fun=58326189, nargs=1, arg_vector=0x82f360) at eval.c:3222
#69 0x01024157 in Ffuncall (nargs=2, args=0x82f35c) at eval.c:3099
#70 0x010233e8 in Fapply (nargs=2, args=0x82f35c) at eval.c:2475
#71 0x01023985 in apply1 (fn=44027457, arg=58381501) at eval.c:2791
#72 0x0111a380 in Fcall_interactively (function=44027457, record_flag=43726897, keys=43760388) at callint.c:389
#73 0x01023ee3 in Ffuncall (nargs=4, args=0x82f618) at eval.c:3048
#74 0x01023a52 in call3 (fn=43921409, arg1=44027457, arg2=43726897, arg3=43726849) at eval.c:2868
#75 0x01015344 in Fcommand_execute (cmd=44027457, record_flag=43726897, keys=43726849, special=43726849) at keyboard.c:10420
#76 0x01015691 in Fexecute_extended_command (prefixarg=43726849) at keyboard.c:10533
#77 0x01023e8a in Ffuncall (nargs=2, args=0x82f850) at eval.c:3042
#78 0x0111bbbb in Fcall_interactively (function=43786841, record_flag=43726849, keys=43760388) at callint.c:857
#79 0x01023ee3 in Ffuncall (nargs=4, args=0x82fb18) at eval.c:3048
#80 0x01023a52 in call3 (fn=43921409, arg1=43786841, arg2=43726849, arg3=43726849) at eval.c:2868
#81 0x01015344 in Fcommand_execute (cmd=43786841, record_flag=43726849, keys=43726849, special=43726849) at keyboard.c:10420
#82 0x01007823 in command_loop_1 () at keyboard.c:1910
#83 0x01021a66 in internal_condition_case (bfun=0x10060cf <command_loop_1>, handlers=43790553, hfun=0x1005acc <cmd_error>) at eval.c:1511
#84 0x01005e18 in command_loop_2 () at keyboard.c:1367
#85 0x01021576 in internal_catch (tag=43786625, func=0x1005df8 <command_loop_2>, arg=43726849) at eval.c:1247
#86 0x01005dcf in command_loop () at keyboard..c:1346
#87 0x010056d2 in recursive_edit_1 () at keyboard.c:955
#88 0x01005840 in Frecursive_edit () at keyboard.c:1017
#89 0x010027dc in main (argc=1, argv=0xa34248) at emacs.c:1762
Lisp Backtrace:
"tar-summarize-buffer" (0x82d654)
"tar-mode" (0x82d8e0)
"progn" (0x82daf8)
"if" (0x82dc08)
"package-untar-buffer" (0x82dcc0)
"let*" (0x82df38)
"let" (0x82e0c8)
"package-unpack" (0x82e180)
"save-excursion" (0x82e3d8)
"let" (0x82e568)
"package-download-tar" (0x82e620)
"cond" (0x82e878)
"let*" (0x82e9e8)
0x37ad455 Lisp type 5
"mapc" (0x82ec60)
"package-download-transaction" (0x82ed70)
"let" (0x82f018)
"let" (0x82f1a8)
"package-install" (0x82f360)
"call-interactively" (0x82f61c)
"execute-extended-command" (0x82f854)
"call-interactively" (0x82fb1c)
On a side note: I am able to install gdb-shell package. Hence, for larger files, something is going wrong!
-dhruva
Explore your hobbies and interests. Go to http://in.promos.yahoo.com/groups/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB debugger mode for Emacs in ELPA
2008-06-27 5:44 filerz-emacs
@ 2008-06-27 6:09 ` Nick Roberts
0 siblings, 0 replies; 8+ messages in thread
From: Nick Roberts @ 2008-06-27 6:09 UTC (permalink / raw)
To: filerz-emacs; +Cc: emacs-devel
> On a side note: I am able to install gdb-shell package. Hence, for larger
> files, something is going wrong!
The package gdb-mi comprises two lisp files stored in a tar file, gdb-shell is
just one lisp file. I suspect you'll get the same error whenever you invoke
tar-summarize-buffer, e.g., visit a tar file in a buffer. It looks like
Emacs can't find the bloc referenced by 0x2ed8a08. I don't understand
enough about memory allocation in r_re_alloc to say what causes it, though.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GDB debugger mode for Emacs in ELPA
2008-06-27 5:30 ` Nick Roberts
@ 2008-06-27 9:15 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2008-06-27 9:15 UTC (permalink / raw)
To: Nick Roberts; +Cc: emacs-devel
> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Fri, 27 Jun 2008 17:30:54 +1200
> Cc: emacs-devel@gnu.org
>
> #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?
As seen from the follow-up, the MinGW build shows the same crash. And
yes, REL_ALLOC should be defined in the Windows build.
Which tarball causes this crash, and where can I find it? Also, would
the OP please post a detailed recipe to reproduce this crash, starting
with "emacs -Q"?
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-06-27 9:15 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-26 5:52 GDB debugger mode for Emacs in ELPA filerz-emacs
2008-06-27 5:30 ` Nick Roberts
2008-06-27 9:15 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2008-06-27 5:44 filerz-emacs
2008-06-27 6:09 ` Nick Roberts
2008-06-26 3:45 filerz-emacs
2008-06-26 4:11 ` Nick Roberts
2008-06-26 1:03 Nick Roberts
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).