[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Gcl-devel] Number_minus problem
From: |
Mike Thomas |
Subject: |
RE: [Gcl-devel] Number_minus problem |
Date: |
Fri, 30 Dec 2005 10:51:24 +1000 |
Thanks Camm.
| Greetings! And thanks as always for your work on this port!
No worries. And also for your ongoing support.
| First, I would really recommend getting gcl malloc working.
| If you get a chance to send me an email like this showing
| that failure, it would be great! If one cannot control
| malloc and ensure it does not interfere with the heap, random
| corruptions are certain!
OK I'll follow up later with same.
| Second, the default gmp alloc is
| now alloc_relblock, meaning that gmp allocations should not
| be invoking malloc at all, rather a special routine
| allocating the bignum data in the very fast relocatable page area.
| Lastly, there seems to be a miscompilation here:
|
| > (gdb) s
| > m__gmpz_set_si (_b=0x3211fe4, _c=10) at ../h/../h/gmp_wrappers.h:142
| > 142 MEM_GMP_CALL(2,void,mpz_set_si,1,mpz_t,long int)
| > (gdb) p /x *(0x812df8)
| > $4 = 0xfeeefeee
| > (gdb) s
| > __gmpz_set_si (dest=0x461482, val=52502500) at set_si.c:27
| > 27 {
| > (gdb) p /x *(0x812df8)
| > $5 = 0xfeeefeee
| > (gdb) p /x 52502500
| > $6 = 0x3211fe4
| >
|
| dest has to be _b, as its just passed through from the
| wrapper. You might want to double check with a bt a few
| steps into __gmpz_set_si to get around any gdb issues, and a
| p dest at the point in question.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: c:\cvs\head\gcl\lsp/../unixport/saved_pre_gcl.exe
../unixport
-system-p -c-file -data-file -o-file nil -h-file -compile gcl_arraylib
Breakpoint 2, __gmpz_set_si (dest=0x461482, val=52502500) at set_si.c:27
27 {
(gdb) bt
#0 __gmpz_set_si (dest=0x461482, val=52502500) at set_si.c:27
#1 0x0044b251 in m__gmpz_set_si (_b=0x3211fe4, _c=10)
at ../h/../h/gmp_wrappers.h:142
#2 0x00461482 in number_minus (x=0xa000000a, y=0xa0000001) at
num_arith.c:395
#3 0x0046396b in Lminus () at num_arith.c:1001
#4 0x0042786b in eval (form=0x4cc540) at eval.c:1107
#5 0x00426ff7 in Ieval (form=0x3261a10) at eval.c:945
#6 0x0041206a in Fsetq (form=0x3261a18) at assignment.c:100
#7 0x004275a4 in eval (form=0x3261a20) at eval.c:1054
#8 0x0044f76b in Floop (form=0x32619f0) at iteration.c:51
#9 0x004275a4 in eval (form=0x3261a28) at eval.c:1054
#10 0x00425bf5 in funcall (fun=0x349ee38) at eval.c:344
#11 0x00425eae in funcall_no_event (fun=0x32614f0) at eval.c:398
#12 0x00427878 in eval (form=0x4cc540) at eval.c:1109
#13 0x00425bf5 in funcall (fun=0x349efb0) at eval.c:344
#14 0x00425eae in funcall_no_event (fun=0x348aa38) at eval.c:398
#15 0x00427878 in eval (form=0x4cc540) at eval.c:1109
#16 0x00425bf5 in funcall (fun=0x349eff0) at eval.c:344
#17 0x00426d4e in super_funcall (fun=0x349ee60) at eval.c:760
#18 0x00402b5b in main (argc=10, argv=0x812608, envp=0x813208) at
main.c:368
#19 0x004011e7 in _end__ ()
#20 0x00401238 in mainCRTStartup ()
#21 0x7c816d4f in _libwsock32_a_iname ()
(gdb) up
#1 0x0044b251 in m__gmpz_set_si (_b=0x3211fe4, _c=10)
at ../h/../h/gmp_wrappers.h:142
142 MEM_GMP_CALL(2,void,mpz_set_si,1,mpz_t,long int)
(gdb) s
30 if (val > 0)
(gdb) p dest
$1 = 0x77c40e66
(gdb) n
27 {
(gdb) n
30 if (val > 0)
(gdb) n
32 dest->_mp_d[0] = val;
(gdb) info frame
Stack level 0, frame at 0x25f8b8:
eip = 0x4b044c in __gmpz_set_si (set_si.c:32); saved eip 0x461482
(FRAMELESS), called by frame at 0x25f8b8
source language c.
Arglist at 0x25f8b8, args: dest=0x461482, val=52502500
Locals at 0x25f8b8, Previous frame's sp is 0x0
Saved registers:
ebp at 0x25f8b8, eip at 0x25f8bc
(gdb) p dest
$2 = 0x3211fe4
**NOTE** dest as shown by "info frame" is different to that shown by "p
dest"??
| Also, start with (setq si::*notify-gbc* t) to see if a gc
| intervenes between the wrapper and the (second) call of the
| real routine (doubtful).
|
A breakpoint on GBC just before the call did not trip.
| Really finally (for now :-)), _mp_d should never be 0x812df8,
| but rather in the heap above the hole. Try a break on gcl_gmp_alloc.
Never happens??
(gdb) b gcl_gmp_alloc
Breakpoint 1 at 0x414e58: file gmp.c, line 5.
(gdb) r
Starting program: c:\cvs\head\gcl\lsp/../unixport/saved_pre_gcl.exe
../unixport
-system-p -c-file -data-file -o-file nil -h-file -compile gcl_arraylib
warning: HEAP[saved_pre_gcl.exe]:
warning: HEAP: Free Heap block 812648 modified at 812df8 after it was
freed
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c901231 in _libwsock32_a_iname ()