I hope you don' t mind me CC'ing my reply to th list.
On Apr 25, 2007, at 9:05 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote: On Apr 25, 2007, at 7:43 PM, dillo gimp wrote:
There might be a bug in big number handling, the same code runs fine under mzscheme and petite, but crashes with gambit : *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
I don't even use "quotient" in my code.
We'd need to see a bit of your code to figure out what you *are* using.
I don't know how to make gambit to report exactly where the code has crashed. The program is not exactly small either. Can you tell me how to make gambit report "crash point"? This is my compilation steps:
cat /lfs/script/gambit.sh #!/bin/bash /usr/4.0b22/bin/gsc -prelude '(define (display x) (write x (current- output-port)))' -link $1 prog=${1%.sc} gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -ldl - lutil
OK, well I still don't know what you're trying to do, but gambit requires gcc to use certain flags for to correctly compile gambit- generated code. See the options in /usr/4.0b22/bin/
Afficher les réponses par date
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote:
I hope you don' t mind me CC'ing my reply to th list.
On Apr 25, 2007, at 9:05 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote: On Apr 25, 2007, at 7:43 PM, dillo gimp wrote:
There might be a bug in big number handling, the same code runs fine under mzscheme and petite, but crashes with gambit : *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
I don't even use "quotient" in my code.
We'd need to see a bit of your code to figure out what you *are* using.
I don't know how to make gambit to report exactly where the code has crashed. The program is not exactly small either. Can you tell me how to make gambit report "crash point"? This is my compilation steps:
cat /lfs/script/gambit.sh #!/bin/bash /usr/4.0b22/bin/gsc -prelude '(define (display x) (write x (current- output-port)))' -link $1 prog=${1%.sc} gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -ldl - lutil
OK, well I still don't know what you're trying to do, but gambit requires gcc to use certain flags for to correctly compile gambit- generated code. See the options in /usr/4.0b22/bin/
I don't understand. I am following the exact steps from: http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html http://www.iro.umontreal.ca/~gambit/doc/gambit-c_toc.html#TOC17
The program only reports: *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
Without a more accurate location, I can't guess what's wrong. The program is not big, but not small either, I can't cut and paste.
Most importantly: I don't use quotient in my code. There shoudn't have any "divide by zero" code, else it would have crashed with other scheme implementations.
On Apr 25, 2007, at 10:25 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote:
I hope you don' t mind me CC'ing my reply to th list.
On Apr 25, 2007, at 9:05 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote: On Apr 25, 2007, at 7:43 PM, dillo gimp wrote:
There might be a bug in big number handling, the same code runs fine under mzscheme and petite, but crashes
with
gambit : *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
I don't even use "quotient" in my code.
We'd need to see a bit of your code to figure out what you *are* using.
I don't know how to make gambit to report exactly where the code has crashed. The program is not exactly small either. Can you tell me how to make gambit report "crash point"? This is my compilation steps:
cat /lfs/script/gambit.sh #!/bin/bash /usr/4.0b22/bin/gsc -prelude '(define (display x) (write x
(current-
output-port)))' -link $1 prog=${1%.sc} gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -
ldl -
lutil
OK, well I still don't know what you're trying to do, but gambit requires gcc to use certain flags for to correctly compile gambit- generated code. See the options in /usr/4.0b22/bin/
I don't understand. I am following the exact steps from: http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html http://www.iro.umontreal.ca/~gambit/doc/gambit-c_toc.html#TOC17
The documentation is in error.
You are compiling your code with the options
gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -
ldl -
These options are incorrect. You can find the correct options on your machine in
/usr/4.0b22/bin/gsc-cc-o
which is in the same directory in which you installed gsi and gsc.
This may be causing your specific problem, but I don't know for sure.
The program only reports: *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
Without a more accurate location, I can't guess what's wrong.
The code for numeric operations is in gambc-4.0b22/lib/_num.scm. There you will find
(define-prim (##ratnum.* x y) (let ((p (macro-ratnum-numerator x)) (q (macro-ratnum-denominator x)) (r (macro-ratnum-numerator y)) (s (macro-ratnum-denominator y))) (if (##eq? x y) (macro-ratnum-make (##* p p) (##* q q)) ; already in lowest form (let* ((gcd-ps (##gcd p s)) (gcd-rq (##gcd r q)) (num (##* (##quotient p gcd-ps) (##quotient r gcd-rq))) (den (##* (##quotient q gcd-rq) (##quotient s gcd-ps)))) (if (##eq? den 1) num (macro-ratnum-make num den))))))
So, somehow, gcd-ps or gcd-rq is zero. ##ratnum.* is called only from ##*, which is the library primitive for multiplication, and ##ratnum.* is only called when one of the arguments of * is a ratnum.
The program is not big, but not small either, I can't cut and paste.
Most importantly: I don't use quotient in my code. There shoudn't have any "divide by zero" code, else it would have crashed with other scheme implementations.
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote:
On Apr 25, 2007, at 10:25 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote:
I hope you don' t mind me CC'ing my reply to th list.
On Apr 25, 2007, at 9:05 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote: On Apr 25, 2007, at 7:43 PM, dillo gimp wrote:
There might be a bug in big number handling, the same code runs fine under mzscheme and petite, but crashes
with
gambit : *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
I don't even use "quotient" in my code.
We'd need to see a bit of your code to figure out what you *are* using.
I don't know how to make gambit to report exactly where the code has crashed. The program is not exactly small either. Can you tell me how to make gambit report "crash point"? This is my compilation steps:
cat /lfs/script/gambit.sh #!/bin/bash /usr/4.0b22/bin/gsc -prelude '(define (display x) (write x
(current-
output-port)))' -link $1 prog=${1%.sc} gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -
ldl -
lutil
OK, well I still don't know what you're trying to do, but gambit requires gcc to use certain flags for to correctly compile gambit- generated code. See the options in /usr/4.0b22/bin/
I don't understand. I am following the exact steps from: http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html http://www.iro.umontreal.ca/~gambit/doc/gambit-c_toc.html#TOC17
The documentation is in error.
You are compiling your code with the options
gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -
ldl -
These options are incorrect. You can find the correct options on your machine in
/usr/4.0b22/bin/gsc-cc-o
which is in the same directory in which you installed gsi and gsc.
This may be causing your specific problem, but I don't know for sure.
The program only reports: *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
Without a more accurate location, I can't guess what's wrong.
The code for numeric operations is in gambc-4.0b22/lib/_num.scm. There you will find
(define-prim (##ratnum.* x y) (let ((p (macro-ratnum-numerator x)) (q (macro-ratnum-denominator x)) (r (macro-ratnum-numerator y)) (s (macro-ratnum-denominator y))) (if (##eq? x y) (macro-ratnum-make (##* p p) (##* q q)) ; already in lowest form (let* ((gcd-ps (##gcd p s)) (gcd-rq (##gcd r q)) (num (##* (##quotient p gcd-ps) (##quotient r gcd-rq))) (den (##* (##quotient q gcd-rq) (##quotient s gcd-ps)))) (if (##eq? den 1) num (macro-ratnum-make num den))))))
So, somehow, gcd-ps or gcd-rq is zero. ##ratnum.* is called only from ##*, which is the library primitive for multiplication, and ##ratnum.* is only called when one of the arguments of * is a ratnum.
The program is not big, but not small either, I can't cut and paste.
Most importantly: I don't use quotient in my code. There shoudn't have any "divide by zero" code, else it would have crashed with other scheme implementations.
I've followed your instructions: cat /usr/4.0b22/bin/gsc-cc-o gcc -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fexpensive-optimizations -fforce-addr -fpeephole2 -falign-jumps -falign-functions -fno-function-cse -fregmove -fgcse-las -freorder-functions -fcaller-saves -fno-if-conversion2 -foptimize-sibling-calls -fcse-skip-blocks -funit-at-a-time -finline-functions -fomit-frame-pointer -fPIC -fno-common -mieee-fp -rdynamic -shared -I${GSC_CC_O_ARG1}include -D___DYNAMIC -D___SINGLE_HOST -o ${GSC_CC_O_ARG2} $* ${GSC_CC_O_ARG3} ... I had to modify the options a little bit because there is no shared library in my installation, and I don't know why. I simply follow the simplest installation steps. Anyway, the program is compiled as static and still crashes exactly. ... gcc -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math \ -fno-strict-aliasing -fwrapv -fexpensive-optimizations -fforce-addr -fpeephole2 \ -falign-jumps -falign-functions -fno-function-cse -fregmove -fgcse-las -freorder-functions \ -fcaller-saves -fno-if-conversion2 -foptimize-sibling-calls -fcse-skip-blocks \ -funit-at-a-time -finline-functions -fomit-frame-pointer -fno-common -mieee-fp \ -I/usr/4.0b22/include -L/usr/4.0b22/lib -D___SINGLE_HOST \ -o $prog $prog.c ${prog}_.c -lgambc -lm -ldl -lutil
The program still carshes without any trace info besides: *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
I've checked the entire program and the only possible divide by zero is (/ (caar a)) which is the same as (/ 1 something) and can't possibly produce (/ 0 0). so, I am out of idea to how debug this program.
Ok, I isolated the code that crashes both gsi and gsc compiled code: it's doing reduced-row-echelon-form. It's a bit long, but this is the best I can do:
;; http://www.cap-lore.com/MathPhys/Field/RREF.html (define (rref x) (if (or (null? x) (null? (car x))) x (let ((a (call-with-current-continuation (lambda (cc) (let df ((y x)) (if (null? y) (cc x) (if (zero? (caar y)) (let ((z (df (cdr y)))) (if (null? z) y (cons (car z) (cons (car y)(cdr z))))) y))))))) (if (zero? (caar a)) (map (lambda (x) (cons 0 x)) (rref (map cdr a))) (let* ( (b (let* ((r (/ (caar a))) (top (map (lambda (z) (* z r)) (car a)))) (cons top (map (lambda (row) (map (lambda (t re) (- re (* t (car row)))) top row)) (cdr a))))) (c (rref (map cdr (cdr b)))) ; now we must ensure a zero in row (cdar b) above each initial 1 a row of c. (d (let w ((sm (cdar b))(i c)) (if (null? i) sm (w (let sr ((x sm) (y (car i))) (if (null? x) '() (if (zero? (car y)) (cons (car x) (sr (cdr x)(cdr y))) (map (lambda (p q)(- p (* (car x) q))) x y)))) (cdr i)))))) (cons (cons 1 d) (map (lambda (x) (cons 0 x)) c)))))))
(define M '((1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4) (1152921504606846976 288230376151711744 72057594037927936 18014398509481984 4503599627370496 1125899906842624 281474976710656 70368744177664 17592186044416 4398046511104 1099511627776 274877906944 68719476736 17179869184 4294967296 1073741824 268435456 67108864 16777216 4194304 1048576 262144 65536 16384 4096 1024 256 64 16 4 1 2) (1073741824 536870912 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 524288 262144 131072 65536 32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1 7) (22539340290692258087863249 3219905755813179726837607 459986536544739960976801 65712362363534280139543 9387480337647754305649 1341068619663964900807 191581231380566414401 27368747340080916343 3909821048582988049 558545864083284007 79792266297612001 11398895185373143 1628413597910449 232630513987207 33232930569601 4747561509943 678223072849 96889010407 13841287201 1977326743 282475249 40353607 5764801 823543 117649 16807 2401 343 49 7 1 3) (205891132094649 68630377364883 22876792454961 7625597484987 2541865828329 847288609443 282429536481 94143178827 31381059609 10460353203 3486784401 1162261467 387420489 129140163 43046721 14348907 4782969 1594323 531441 177147 59049 19683 6561 2187 729 243 81 27 9 3 1 508) (1499378808754598535585630628499515809512621559292630070002567432363673096997044224 2951533088099603416507146906495109861245318030103602500005054000715891923222528 5810104504133077591549501784439192640246689035637012795285539371487976226816 11437213590813144865254924772518095748517104400860261408042400337574756352 22514199981915639498533316481334834150624221261535947653626772318060544 44319291302983542319947473388454397934299648152629818215800732909568 87242699415321933700684002733177948689566236520924839007481757696 171737597274255775001346462073184938365287867167174879935987712 338066136366645226380603271797608146388361943242470236094464 665484520406781941694100928735449107063704612682028023808 1310008898438547129319096316408364383983670497405566976 2578757674091628207321055740961347212566280506703872 5076294634038638203387905001892415772768268713984 9992705972517004337377765751756723962142261248 19670681048261819561767255416843944807366656 38721813087129566066470975230007765368832 76224041510097570996990108720487727104 150047325807278683064941158898597888 295368751589131265875868423028736 581434550372305641487929966592 1144556201520286695842381824 2253063388819461999689728 4435164151219413385216 8730638092951601152 17186295458566144 33831290272768 66597028096 131096512 258064 508 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 5) (931322574615478515625 186264514923095703125 37252902984619140625 7450580596923828125 1490116119384765625 298023223876953125 59604644775390625 11920928955078125 2384185791015625 476837158203125 95367431640625 19073486328125 3814697265625 762939453125 152587890625 30517578125 6103515625 1220703125 244140625 48828125 9765625 1953125 390625 78125 15625 3125 625 125 25 5 1 5) (931322574615478515625 186264514923095703125 37252902984619140625 7450580596923828125 1490116119384765625 298023223876953125 59604644775390625 11920928955078125 2384185791015625 476837158203125 95367431640625 19073486328125 3814697265625 762939453125 152587890625 30517578125 6103515625 1220703125 244140625 48828125 9765625 1953125 390625 78125 15625 3125 625 125 25 5 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2) (1073741824 536870912 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 524288 262144 131072 65536 32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 24) (254880876153761202627773829926908776677376 10620036506406716776157242913621199028224 442501521100279865673218454734216626176 18437563379178327736384102280592359424 768231807465763655682670928358014976 32009658644406818986777955348250624 1333735776850284124449081472843776 55572324035428505185378394701824 2315513501476187716057433112576 96479729228174488169059713024 4019988717840603673710821376 167499529910025153071284224 6979147079584381377970176 290797794982682557415424 12116574790945106558976 504857282956046106624 21035720123168587776 876488338465357824 36520347436056576 1521681143169024 63403380965376 2641807540224 110075314176 4586471424 191102976 7962624 331776 13824 576 24 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 3) (205891132094649 68630377364883 22876792454961 7625597484987 2541865828329 847288609443 282429536481 94143178827 31381059609 10460353203 3486784401 1162261467 387420489 129140163 43046721 14348907 4782969 1594323 531441 177147 59049 19683 6561 2187 729 243 81 27 9 3 1 3) (205891132094649 68630377364883 22876792454961 7625597484987 2541865828329 847288609443 282429536481 94143178827 31381059609 10460353203 3486784401 1162261467 387420489 129140163 43046721 14348907 4782969 1594323 531441 177147 59049 19683 6561 2187 729 243 81 27 9 3 1 30) (205891132094649000000000000000000000000000000 6863037736488300000000000000000000000000000 228767924549610000000000000000000000000000 7625597484987000000000000000000000000000 254186582832900000000000000000000000000 8472886094430000000000000000000000000 282429536481000000000000000000000000 9414317882700000000000000000000000 313810596090000000000000000000000 10460353203000000000000000000000 348678440100000000000000000000 11622614670000000000000000000 387420489000000000000000000 12914016300000000000000000 430467210000000000000000 14348907000000000000000 478296900000000000000 15943230000000000000 531441000000000000 17714700000000000 590490000000000 19683000000000 656100000000 21870000000 729000000 24300000 810000 27000 900 30 1 4) (1152921504606846976 288230376151711744 72057594037927936 18014398509481984 4503599627370496 1125899906842624 281474976710656 70368744177664 17592186044416 4398046511104 1099511627776 274877906944 68719476736 17179869184 4294967296 1073741824 268435456 67108864 16777216 4194304 1048576 262144 65536 16384 4096 1024 256 64 16 4 1 10) (1000000000000000000000000000000 100000000000000000000000000000 10000000000000000000000000000 1000000000000000000000000000 100000000000000000000000000 10000000000000000000000000 1000000000000000000000000 100000000000000000000000 10000000000000000000000 1000000000000000000000 100000000000000000000 10000000000000000000 1000000000000000000 100000000000000000 10000000000000000 1000000000000000 100000000000000 10000000000000 1000000000000 100000000000 10000000000 1000000000 100000000 10000000 1000000 100000 10000 1000 100 10 1 158) (911407522138190370523336355973946907449902506716804668278098100224 5768402038849306142552761746670550047151281688081042204291760128 36508873663603203433878238902978164855387858785323051925897216 231068820655716477429609106980874461110049739147614252695552 1462460890226053654617779158106800386772466703465912991744 9256081583709200345682146570296204979572574072569069568 58582794833602533833431307406938006199826418180816896 370777182491155277426780426626189912657129228992512 2346691028425033401435319155861961472513476132864 14852474863449578490096956682670642231097950208 94003005464870749937322510649814191336062976 594955730790321202134952599049456907190272 3765542599938741785664256956009220931584 23832548100878112567495297189931778048 150838912030874130174020868290707456 954676658423253988443170052472832 6042257331792746762298544635904 38242135011346498495560409088 242038829185737332250382336 1531891323960362862344192 9695514708609891533824 61364017143100579328 388379855336079616 2458100350228352 15557597153344 98465804768 623201296 3944312 24964 158 1 6) (221073919720733357899776 36845653286788892983296 6140942214464815497216 1023490369077469249536 170581728179578208256 28430288029929701376 4738381338321616896 789730223053602816 131621703842267136 21936950640377856 3656158440062976 609359740010496 101559956668416 16926659444736 2821109907456 470184984576 78364164096 13060694016 2176782336 362797056 60466176 10077696 1679616 279936 46656 7776 1296 216 36 6 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1) (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2) (1073741824 536870912 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 524288 262144 131072 65536 32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1 12) (237376313799769806328950291431424 19781359483314150527412524285952 1648446623609512543951043690496 137370551967459378662586974208 11447545997288281555215581184 953962166440690129601298432 79496847203390844133441536 6624737266949237011120128 552061438912436417593344 46005119909369701466112 3833759992447475122176 319479999370622926848 26623333280885243904 2218611106740436992 184884258895036416 15407021574586368 1283918464548864 106993205379072 8916100448256 743008370688 61917364224 5159780352 429981696 35831808 2985984 248832 20736 1728 144 12 1 1))) (display (rref M))(newline)
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote:
On Apr 25, 2007, at 10:25 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote:
I hope you don' t mind me CC'ing my reply to th list.
On Apr 25, 2007, at 9:05 PM, dillo gimp wrote:
On 4/26/07, Bradley Lucier lucier@math.purdue.edu wrote: On Apr 25, 2007, at 7:43 PM, dillo gimp wrote:
There might be a bug in big number handling, the same code runs fine under mzscheme and petite, but crashes
with
gambit : *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
I don't even use "quotient" in my code.
We'd need to see a bit of your code to figure out what you *are* using.
I don't know how to make gambit to report exactly where the code has crashed. The program is not exactly small either. Can you tell me how to make gambit report "crash point"? This is my compilation steps:
cat /lfs/script/gambit.sh #!/bin/bash /usr/4.0b22/bin/gsc -prelude '(define (display x) (write x
(current-
output-port)))' -link $1 prog=${1%.sc} gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -
ldl -
lutil
OK, well I still don't know what you're trying to do, but gambit requires gcc to use certain flags for to correctly compile gambit- generated code. See the options in /usr/4.0b22/bin/
I don't understand. I am following the exact steps from: http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html http://www.iro.umontreal.ca/~gambit/doc/gambit-c_toc.html#TOC17
The documentation is in error.
You are compiling your code with the options
gcc -O2 -fomit-frame-pointer -freg-struct-return \ -I/usr/4.0b22/include -L/usr/4.0b22/lib \ -D___SINGLE_HOST -o $prog $prog.c ${prog}_.c -lgambc -lm -
ldl -
These options are incorrect. You can find the correct options on your machine in
/usr/4.0b22/bin/gsc-cc-o
which is in the same directory in which you installed gsi and gsc.
This may be causing your specific problem, but I don't know for sure.
The program only reports: *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
Without a more accurate location, I can't guess what's wrong.
The code for numeric operations is in gambc-4.0b22/lib/_num.scm. There you will find
(define-prim (##ratnum.* x y) (let ((p (macro-ratnum-numerator x)) (q (macro-ratnum-denominator x)) (r (macro-ratnum-numerator y)) (s (macro-ratnum-denominator y))) (if (##eq? x y) (macro-ratnum-make (##* p p) (##* q q)) ; already in lowest form (let* ((gcd-ps (##gcd p s)) (gcd-rq (##gcd r q)) (num (##* (##quotient p gcd-ps) (##quotient r gcd-rq))) (den (##* (##quotient q gcd-rq) (##quotient s gcd-ps)))) (if (##eq? den 1) num (macro-ratnum-make num den))))))
So, somehow, gcd-ps or gcd-rq is zero. ##ratnum.* is called only from ##*, which is the library primitive for multiplication, and ##ratnum.* is only called when one of the arguments of * is a ratnum.
The program is not big, but not small either, I can't cut and paste.
Most importantly: I don't use quotient in my code. There shoudn't have any "divide by zero" code, else it would have crashed with other scheme implementations.
dillo gimp wrote:
Ok, I isolated the code that crashes both gsi and gsc compiled code: it's doing reduced-row-echelon-form. It's a bit long, but this is the best I can do:
Bugs happen.
(This is a somewhat lengthy demonstration of debugging; the relevant finding is at the end of this mail.)
For debugging, it's often best to switch off tail call optimization, so that really the error is reported in the scope where the triggering code is situated is reported and not the place of the next outer non-tail continuation after elimination of all 'empty' continuations.
It helps using the provided gambit elisp file with Emacs, this way you can have keys bound to the debugger commands, and Emacs automatically jumps to the place in the sources where the debugger is hinting at.
(generate-proper-tail-calls #f) (load "bignumbug.scm")
*** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0)
Now you can make use of the fine Gambit debugger:
1> ,b 0 ##ratnum.* 1 * 2 #<procedure #4> "bignumbug.scm"@21:31 (* z r) 3 map 4 rref "bignumbug.scm"@21:14 (map (lambda (z) (* z r... 5 rref "bignumbug.scm"@19:35 (rref (map cdr a)) 6 rref "bignumbug.scm"@19:35 (rref (map cdr a)) 7 rref "bignumbug.scm"@19:35 (rref (map cdr a)) 8 rref "bignumbug.scm"@28:9 (rref (map cdr (cdr b))) 9 rref "bignumbug.scm"@28:9 (rref (map cdr (cdr b))) ... 20 rref "bignumbug.scm"@28:9 (rref (map cdr (cdr b))) 21 test "bignumbug.scm"@223:12 (rref M) 22 (interaction) (stdin)@22:1 (test) 23 ##main
The first two are part of the system (and hence, because the Gambit system has not been compiled with debuggig enabled, doesn't report file/line information). The fist continuation in your code is continuation 2.
1> ,2 2 #<procedure #4> "bignumbug.scm"@21.31 (* z r) 1\2> z 0/2 1\2> r 2/0
This looks 'interesting', both 0/2 and 2/0.
1\2> (* z 3) 0/2 1\2> (* 3 r) 2/0 1\2> (* z r) *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0) 2>
Hit Ctl-d once to get back to the previous debugging level.
The call is in the lambda in this code:
(let* ((b (let* ((r (/ (caar a))) (top (map (lambda (z) (* z r)) (car a))))
How did r happen to be 2/0? From (/ (caar a)). We can see the rest of the environment:
1\2> ,e z = 0/2 r = 2/0 a = '((0/2 0/8 0/32 0/128 0/512 0/2048 0/8192 0/32768 0/131072 0/524288 0/20... x = '((0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4) (0... (current-exception-handler) = primordial-exception-handler (current-input-port) = '#<input-port #2 (stdin)> (current-output-port) = '#<output-port #3 (stdout)> (current-directory) = "/home/chris/schemedevelopment/gambit/work/"
So a is a list with those strange numbers.
1\2> (caar a) 0/2
1\2> a ((0/2 0/8 0/32 0/128 0/512 0/2048 0/8192 0/32768 0/131072 0/524288 0/2097152 0/8388608 0/33554432 0/134217728 0/134217728 -805306368/134217728) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3) ...
Next step is to find out how those values in a are being produced. I'll use the stepper. I'm instrumenting the code with a (step) like so:
(let ((a (call-with-current-continuation (lambda (cc) (step) ;; <---switch on stepping (let df ((y x)) (if (null? y) (cc x) (if (zero? (caar y)) (let ((z (df (cdr y)))) (if (null? z) y (cons (car z) (cons (car y)(cdr z))))) y)))))))
Stepping through I see that the last branch is taken, y is returned, the unchanged x. Not interesting yet. The problem must happen in a later recursive call of rref. So I'm entering 1> ,c
Next rref run is not interesting either, I'm hitting ,c about 10 times now x is:
1> x ((0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -4) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) (0 0 ...
Still no interesting effect though.
What we want is see how a is being built right before the error happens.
Using call/cc we can save previous state of a computation:
(define lastcc #f) ... (let ((a (begin (call/cc (lambda (cc) (set! lastcc cc))) (call-with-current-continuation (lambda (cc) ;;(step) (let df ((y x))
I'm running the code again, *** ERROR IN ##ratnum.* -- Divide by zero (quotient 0 0) 1> hit ctl-d, then
(begin (step) (lastcc))
and step through the code
1> x ((0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -4) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) (0/2 0/8 0/32
hm, it already contains such numbers. The problematic operations have happened earlier already. Well, let's change the debugging hooks again, to
(define lastcc '()) ... (call/cc (lambda (cc) (set! lastcc (cons cc lastcc))))
Run the code again, will get you all those continuations in reverse order.
lastcc
(#<procedure #23> #<procedure #24> #<procedure #25> #<procedure #26> #<procedure #27> #<procedure #28> #<procedure #29> #<procedure #30> #<procedure #31> #<procedure #32> #<procedure #33> #<procedure #34> #<procedure #35> #<procedure #36> #<procedure #37> #<procedure #38> #<procedure #39>)
I check the one before the last:
(begin (step) (#24))
,s ,s ,s..
then I check the others #30 -> x already contains buggy rationals, #38 -> x does not yet contain buggy rationals, #35 -> x already contains buggy rationals: .. (0 0 0 0 0 0 0 0 0 0 0 0 0/2 0/8 0/32 0/128 0/512 0/2048 0/8192 0/32768 0/131072 0/524288 0/2097152 0/8388608 0/33554432 0/134217728 0/134217728 -805306368/134217728) ..
#36 -> contains same as #35 #37 -> x does not yet contain those values.
Ok, so we can just continue to step on beginning from #37, that should lead us to the buggy op.
Instead of entering the ,s command many times manually, I'm switching to the *scratch* buffer, enter
(dotimes (i 1000) (gambit-step-continuation)) ; or use 2000 to make sure you get to it
and hit ctl-j. Then I switch back to the *scheme* buffer and search for 0/ in the buffer from the start of the stepping. This gives me this relevant cutout:
1> | | | > re | | | -2147450880/2 *** STOPPED IN #<procedure #79>, "bignumbug.scm"@30.17 1> | | | > * | | | #<procedure #66 *> *** STOPPED IN #<procedure #79>, "bignumbug.scm"@30.19 1> | | | > t | | | 65535/8192 *** STOPPED IN #<procedure #79>, "bignumbug.scm"@30.22 1> | | | > car | | | #<procedure #62 car> *** STOPPED IN #<procedure #79>, "bignumbug.scm"@30.26 1> | | | > row | | | (-134217728 -234881024 -293601280 -325058560 -341311488 -349569024 -353... *** STOPPED IN #<procedure #79>, "bignumbug.scm"@30.21 1> | | | > (car row) | | | -134217728 *** STOPPED IN #<procedure #79>, "bignumbug.scm"@30.16 1> | | | > (* t (car row)) | | | -1073725440 *** STOPPED IN #<procedure #79>, "bignumbug.scm"@30.10 1> | | | > (- re (* t (car row))) | | | 0/2
Using those values:
(- -2147450880/2 -1073725440)
0 where the above has given 0/2. Well, I'm out of idea now, I hope Marc or Brad can help further.
BTW, another idea to help track down the above numbers would have been to wrap the gambit ops with ones that check the result for not containing a zero numerator or denominator and throw an error right away if it does. This would have been easier than the above, but my description may help you anyway.
(BTW I'm using 4.0 beta 21)
Christian.
PS. I've already suggested once to add a mode to the debugger to save all continuations onto a stack. So instead of recording everything into the Emacs buffer as shown above, the continuations would be on a stack/list which could be examined, that could maybe be more efficient computation-wise and maybe offer better handling.
PS.2: Gambit shouldn't exit if ,s is entered on the toplevel. (This makes using repeated ,s dangerous since one too many and the collected data of the running interpreter is lost.)
On Apr 26, 2007, at 7:44 AM, Christian Jaeger wrote:
BTW, another idea to help track down the above numbers would have been to wrap the gambit ops with ones that check the result for not containing a zero numerator or denominator and throw an error right away if it does. This would have been easier than the above, but my description may help you anyway.
Yeah, that's what I ended up doing.
Brad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 26-Apr-07, at 7:44 AM, Christian Jaeger wrote:
Using those values:
(- -2147450880/2 -1073725440)
0 where the above has given 0/2. Well, I'm out of idea now, I hope Marc or Brad can help further.
BTW, another idea to help track down the above numbers would have been to wrap the gambit ops with ones that check the result for not containing a zero numerator or denominator and throw an error right away if it does. This would have been easier than the above, but my description may help you anyway.
(BTW I'm using 4.0 beta 21)
Christian.
I am deeply impressed! You get my vote for the "Gambit debugger man of the year" award!
PS. I've already suggested once to add a mode to the debugger to save all continuations onto a stack. So instead of recording everything into the Emacs buffer as shown above, the continuations would be on a stack/list which could be examined, that could maybe be more efficient computation-wise and maybe offer better handling.
Can you elaborate? Which continuations do you want to save?
PS.2: Gambit shouldn't exit if ,s is entered on the toplevel. (This makes using repeated ,s dangerous since one too many and the collected data of the running interpreter is lost.)
Good point. I'll change ,s and ,l so that they prevent that from happening.
Marc
Marc Feeley wrote:
I am deeply impressed! You get my vote for the "Gambit debugger man of the year" award!
Thanks.
PS. I've already suggested once to add a mode to the debugger to save all continuations onto a stack. So instead of recording everything into the Emacs buffer as shown above, the continuations would be on a stack/list which could be examined, that could maybe be more efficient computation-wise and maybe offer better handling.
Can you elaborate? Which continuations do you want to save?
Every (implicit) continuation the interpreter is seeing. (All function calls.)
Example: this code
(define (test a) (println (+ (/ a 2) 3)))
would be evaluated as
(define (test_ a) (R println (R + (R / a 2) 3)))
with the following library:
(define conts '()) ;; (should be per-thread or so, too)
;; hmm using parameters doesn't work, they are tied to the dynamic env in the continuations ; (define record? (make-parameter #t)) ; (define (replay c) ; (parameterize ((record? #f)) ; (c))) ;; so using a normal global instead: (define _record? #t) (define record? (& _record?)) ;; remember, & is my thunk macro (define (replay c) (dynamic-wind (& (set! _record? #f)) c (& ;; (set! _record? #t) hehe, dynamic-wind "doesn't work" either, of course, have to leave it switched off. #!void)))
(define (addcont! c) (if (record?) (set! conts (cons c conts))))
(define (R fn . args) (call/cc (lambda (cc) (addcont! cc))) (apply fn args))
;this would be an alternative allowing to feed different values when replaying: ; (define (R fn . args) ; (call/cc (lambda (cc) ; (addcont! cc) ; (apply fn args))))
(BTW I'm surprised about the behaviour of parameterize/dynamic-wind: I expected it to behave like delay/force, e.g. to not store the environment of the creation but adopt the one of the current caller. But I think I see that's not possible or e.g. exception mechanism semantics wouldn't work etc.; but the weird consequence of this is that I don't see a thread-safe, or scoped, way to tell replays to not record continuations again. Maybe I'm not fully clear about it really myself?)
Of course there would be many continuations during normal runs, and I would suggest to offer a callback mechanism to let the user choose how he wants to keep them, examples would be a ring structure (vector) of fixed size, and maybe only keep every 100th continuation or so (requiring to step forward again up to the relevant place). Ocaml's debugger is using fork(2) for the same purpose (fork a new child every nth operation).
(BTW the link to my message I've mentioned: https://webmail.iro.umontreal.ca/pipermail/gambit-list/2006-January/000579.h...)
PS.2: Gambit shouldn't exit if ,s is entered on the toplevel. (This makes using repeated ,s dangerous since one too many and the collected data of the running interpreter is lost.)
Good point. I'll change ,s and ,l so that they prevent that from happening.
..and ,c too, actually.
Christian.
You're absolutely right, there is a bug in runtime library. Thanks for reporting it. (This code is from 1998 ;-)
Specifically, in ##exact-int.div, it assumes that the quotient of a fixnum by a bignum is zero, but that's not true when the fixnum is the least fixnum and the bignum is the negation of the least fixnum.
Debugging info follows.
Brad
Once I saw that you were using rational arithmetic, I decided to add code to the to top of the file to check the arguments and results of +, -, *, and / by
(define (proper-rational? r) (and (exact? r) (or (integer? r) (let ((p (numerator r)) (q (denominator r))) (and (exact? p) (integer? p) (exact? q) (integer? q) (< 0 q) (= 1 (gcd p q)))))))
(define (every? p l) (or (null? l) (and (p (car l)) (every? p (cdr l)))))
(define-macro (check-math-ops) (define (symbol-append . args) (string->symbol (apply string-append (map (lambda (x) (if (string? x) x (symbol->string x))) args))))
`(let (,@(map (lambda (op) `(,(symbol-append 'orig- op) ,op)) '(+ - * /))) ,@(map (lambda (op) (let ((orig-op (symbol-append 'orig- op))) `(set! ,op (lambda args (if (not (every? proper-rational? args)) (error "args" ,orig-op args)) (let ((result (apply ,orig-op args))) (if (proper-rational? result) result (error "result" ,orig-op args))))))) '(+ - * /))))
(check-math-ops)
That showed
[brad:~/Desktop/dillo] lucier% gsi Gambit Version 4.0 beta 22
(generate-proper-tail-calls #f) (load "test.scm")
*** ERROR IN *, "test.scm"@34.1 -- result #<procedure #2> (1431655765/1073741824 -536870912) 1> ,b 0 * "test.scm"@34:1 (error "result" orig-* args) 1 #<procedure #3> "test.scm"@61:13 (* t (car row)) 2 map 3 map 4 map 5 map 6 map 7 map 8 map 9 map ... 23 (interaction) "test.scm"@271:10 (rref M) 24 ##load 25 ##load 26 (interaction) (console)@2:1 (load "test.scm") 1> ,e result = 0/2 args = '(1431655765/1073741824 -536870912) orig-+ = '#<procedure #4> orig-- = '#<procedure #5> orig-* = '#<procedure #2> orig-/ = '#<procedure #6> (current-exception-handler) = primordial-exception-handler (current-input-port) = '#<input-output-port #7 (console)> (current-output-port) = '#<input-output-port #7 (console)> (current-directory) = "/Users/lucier/Desktop/dillo/"
So #<procedure #2> is orig-*, so the error is in *. (We already knew it was in ##ratnum.* from the first error message.) So I pulled out ##ratnum.* and its associated macros from _num.scm, _num#.scm, and header.scm:
(##define-macro (macro-slot index struct . val) (if (null? val) `(##vector-ref ,struct ,index) `(##vector-set! ,struct ,index ,@val)))
(##define-macro (macro-ratnum-make num den) `(##subtype-set! (##vector ,num ,den) (macro-subtype-ratnum)))
(##define-macro (macro-ratnum-numerator r) `(macro-slot 0 ,r)) (##define-macro (macro-ratnum-numerator-set! r x) `(macro-slot 0 ,r ,x)) (##define-macro (macro-ratnum-denominator r) `(macro-slot 1 ,r)) (##define-macro (macro-ratnum-denominator-set! r x) `(macro-slot 1 ,r ,x)) (##define-macro (macro-subtype-ratnum) 2)
(define (ratnum.* x y) (let ((p (macro-ratnum-numerator x)) (q (macro-ratnum-denominator x)) (r (macro-ratnum-numerator y)) (s (macro-ratnum-denominator y))) (step) (if (##eq? x y) (macro-ratnum-make (##* p p) (##* q q)) ; already in lowest form (let* ((gcd-ps (##gcd p s)) (gcd-rq (##gcd r q)) (num (##* (##quotient p gcd-ps) (##quotient r gcd-rq))) (den (##* (##quotient q gcd-rq) (##quotient s gcd-ps)))) (if (##eq? den 1) num (macro-ratnum-make num den))))))
and stepped through
(trace ##+ ##* ##gcd ##quotient)
*** WARNING -- Rebinding global variable "##+" to an interpreted procedure *** WARNING -- Rebinding global variable "##*" to an interpreted procedure *** WARNING -- Rebinding global variable "##gcd" to an interpreted procedure *** WARNING -- Rebinding global variable "##quotient" to an interpreted procedure
(ratnum.* 1431655765/1073741824 (##ratnum.<-exact-int -536870912))
There I found that (##gcd -536870912 1073741824) is 536870912 and eventually
1> ,s | > (##quotient r gcd-rq) | | > (##quotient -536870912 536870912) | | 0 | 0
and if you trace why that happens, -536870912 is a fixnum (the least fixnum) and 536870912 is a bignum, and in ##exact-int.div we find the buggy code
(if (##fixnum? x) (if (##fixnum? y) (##cons (##fixnum.quotient x y) ; note: y can't be -1 (##fixnum.remainder x y)) (##cons 0 x))
so it assumes that the quotient of a fixnum with a bignum is zero, which, as we find out here is not true.
Brad
Here's a fix for the bug. (Marc, can you change this in _num.scm?)
In the directory gambc-4.0b22 do a
make bootstrap
and then replace ##exact-int.div in lib/_num.scm with
(define-prim (##exact-int.div x y) (cond ((##eq? y 1) (##cons x 0)) ((##eq? y -1) (##cons (##negate x) 0)) ((##eq? x y) ;; can come up in rational arithmetic (##cons 1 0)) ((and (##fixnum? x) (##fixnum? y)) (##cons (##fixnum.quotient x y) ; note: y can't be -1 (##fixnum.remainder x y))) (else (let* ((x-negative? (##negative? x)) (abs-x (if x-negative? (##negate x) x)) (y-negative? (##negative? y)) (abs-y (if y-negative? (##negate y) y))) (if (##< abs-x abs-y) (##cons 0 x)
;; at least one of x and y is a bignum, so ;; here abs-x must be a bignum
(let ((result (##bignum.div abs-x abs-y)))
(if (##not (##eq? x-negative? y-negative?)) (##set-car! result (##negate (##car result))))
(if x-negative? (##set-cdr! result (##negate (##cdr result))))
result))))))
then do a make/make install again. The program now works.
BTW, "display" in gambit does
(display '(1 2 3 4 5))
12345>
which I presume is not what you want at the end of your test program, so I suggest you replace "display" with "pretty-print" or "write".
Brad
On Apr 26, 2007, at 11:47 AM, Bradley Lucier wrote:
Here's a fix for the bug. (Marc, can you change this in _num.scm?)
Here's a somewhat better fix (faster for some "obvious" cases, which I hope are correct ;-).
(define-prim (##exact-int.div x y)
(define (big-quotient x y) (let* ((x-negative? (##negative? x)) (abs-x (if x-negative? (##negate x) x)) (y-negative? (##negative? y)) (abs-y (if y-negative? (##negate y) y))) (if (##< abs-x abs-y) (##cons 0 x) ;; at least one of x and y is a bignum, so ;; here abs-x must be a bignum (let ((result (##bignum.div abs-x abs-y))) (if (##not (##eq? x-negative? y-negative?)) (##set-car! result (##negate (##car result)))) (if x-negative? (##set-cdr! result (##negate (##cdr result)))) result))))
(cond ((##eq? y 1) (##cons x 0)) ((##eq? y -1) (##cons (##negate x) 0)) ((##eq? x y) ;; can come up in rational arithmetic (##cons 1 0)) ((##fixnum? x) (if (##fixnum? y) (##cons (##fixnum.quotient x y) ; note: y can't be -1 (##fixnum.remainder x y)) ;; y is a bignum, x is a fixnum (if (##fixnum.< 1 (##bignum.adigit-length y)) ;; y has at least two adigits, so ;; (abs y) > (abs x) (##cons 0 x) (big-quotient x y)))) ((and (##bignum? y) (##fixnum.< 1 (##fixnum.- (##bignum.adigit-length y) (##bignum.adigit-length x)))) ;; x and y are bignums, and y has at least two more adigits ;; than x, so (abs y) > (abs x) (##cons 0 x)) (else (big-quotient x y))))
On 4/27/07, Bradley Lucier lucier@math.purdue.edu wrote:
On Apr 26, 2007, at 11:47 AM, Bradley Lucier wrote:
Here's a fix for the bug. (Marc, can you change this in _num.scm?)
Here's a somewhat better fix (faster for some "obvious" cases, which I hope are correct ;-).
(define-prim (##exact-int.div x y)
(define (big-quotient x y) (let* ((x-negative? (##negative? x)) (abs-x (if x-negative? (##negate x) x)) (y-negative? (##negative? y)) (abs-y (if y-negative? (##negate y) y))) (if (##< abs-x abs-y) (##cons 0 x)
;; at least one of x and y is a bignum, so ;; here abs-x must be a bignum (let ((result (##bignum.div abs-x abs-y))) (if (##not (##eq? x-negative? y-negative?)) (##set-car! result (##negate (##car result)))) (if x-negative? (##set-cdr! result (##negate (##cdr result)))) result))))(cond ((##eq? y 1) (##cons x 0)) ((##eq? y -1) (##cons (##negate x) 0)) ((##eq? x y) ;; can come up in rational arithmetic (##cons 1 0)) ((##fixnum? x) (if (##fixnum? y) (##cons (##fixnum.quotient x y) ; note: y can't be -1 (##fixnum.remainder x y)) ;; y is a bignum, x is a fixnum (if (##fixnum.< 1 (##bignum.adigit-length y)) ;; y has at least two adigits, so ;; (abs y) > (abs x) (##cons 0 x) (big-quotient x y)))) ((and (##bignum? y) (##fixnum.< 1 (##fixnum.- (##bignum.adigit-length y) (##bignum.adigit-length x)))) ;; x and y are bignums, and y has at least two more adigits ;; than x, so (abs y) > (abs x) (##cons 0 x)) (else (big-quotient x y))))
Is this "make check" error OK to ignore? It didn't happen before. ------------ TEST 4 (interpreter running an application) rm -f mix.o ../gsi/gsi -f mix.scm > test4.out 6.352035 secs elapsed cpu time heartbeat frequency = 893.414472684738 Hz *** possible problem: expected heartbeat frequency = 1001.0010010010009 Hz diff test4.ok test4.out && rm -f test4.out 8450,8451c8450 < *** ERROR IN ##make-string -- Heap overflow < ok ---
(expected error)
make[1]: *** [test4] Error 1 make[1]: Leaving directory `/build/gambc-4.0b22/tests' make: *** [check] Error 2
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On 4/27/07, dillo gimp dillogimp@gmail.com wrote:
On 4/27/07, Bradley Lucier lucier@math.purdue.edu wrote:
On Apr 26, 2007, at 11:47 AM, Bradley Lucier wrote:
Here's a fix for the bug. (Marc, can you change this in _num.scm?)
Here's a somewhat better fix (faster for some "obvious" cases, which I hope are correct ;-).
(define-prim (##exact-int.div x y)
(define (big-quotient x y) (let* ((x-negative? (##negative? x)) (abs-x (if x-negative? (##negate x) x)) (y-negative? (##negative? y)) (abs-y (if y-negative? (##negate y) y))) (if (##< abs-x abs-y) (##cons 0 x)
;; at least one of x and y is a bignum, so ;; here abs-x must be a bignum (let ((result (##bignum.div abs-x abs-y))) (if (##not (##eq? x-negative? y-negative?)) (##set-car! result (##negate (##car result)))) (if x-negative? (##set-cdr! result (##negate (##cdr result)))) result))))(cond ((##eq? y 1) (##cons x 0)) ((##eq? y -1) (##cons (##negate x) 0)) ((##eq? x y) ;; can come up in rational arithmetic (##cons 1 0)) ((##fixnum? x) (if (##fixnum? y) (##cons (##fixnum.quotient x y) ; note: y can't be -1 (##fixnum.remainder x y)) ;; y is a bignum, x is a fixnum (if (##fixnum.< 1 (##bignum.adigit-length y)) ;; y has at least two adigits, so ;; (abs y) > (abs x) (##cons 0 x) (big-quotient x y)))) ((and (##bignum? y) (##fixnum.< 1 (##fixnum.- (##bignum.adigit-length y) (##bignum.adigit-length x)))) ;; x and y are bignums, and y has at least two more adigits ;; than x, so (abs y) > (abs x) (##cons 0 x)) (else (big-quotient x y))))
Is this "make check" error OK to ignore? It didn't happen before. ------------ TEST 4 (interpreter running an application) rm -f mix.o ../gsi/gsi -f mix.scm > test4.out 6.352035 secs elapsed cpu time heartbeat frequency = 893.414472684738 Hz *** possible problem: expected heartbeat frequency = 1001.0010010010009 Hz diff test4.ok test4.out && rm -f test4.out 8450,8451c8450 < *** ERROR IN ##make-string -- Heap overflow
< ok
(expected error)
make[1]: *** [test4] Error 1 make[1]: Leaving directory `/build/gambc-4.0b22/tests' make: *** [check] Error 2
The error disappear after I take out "--enable-char-size=1".
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Dillo:
Is this "make check" error OK to ignore? It didn't happen before. ------------ TEST 4 (interpreter running an application) rm -f mix.o ../gsi/gsi -f mix.scm > test4.out 6.352035 secs elapsed cpu time heartbeat frequency = 893.414472684738 Hz *** possible problem: expected heartbeat frequency = 1001.0010010010009 Hz diff test4.ok test4.out && rm -f test4.out 8450,8451c8450 < *** ERROR IN ##make-string -- Heap overflow
< ok
(expected error)
make[1]: *** [test4] Error 1 make[1]: Leaving directory `/build/gambc-4.0b22/tests' make: *** [check] Error 2
The error disappear after I take out "--enable-char-size=1".
It's a bug in the test suite. There's another thread on this dated April 6 on the rchives. You can find it by searching on Google with this query:
site:https://webmail.iro.umontreal.ca/pipermail/gambit-list/ enable-char-size=1
Where you can replace "enable-char-size=1" with anything you want to search the archives for.
TJ
-
Bradley Lucier -
Christian Jaeger -
dillo gimp -
Marc Feeley -
TJ