Hi Gambit list,
I've started getting segmentation faults whenever I compile srfi-1.scm[1] and use it within my program and was wondering if it was to do with non-tail recursion.
I did a quick experiment and found that on my machine the following code compiled with gsc segfaults when i is just 20000 (it works fine interpreted):
--------------
(define (loop i) (if (zero? i) '() (cons i (loop (- i 1)))))
(loop 20000)
--------------
This seems quite limiting - is there flag I can tweak to improve this?
Many thanks,
Phil
[1] https://webmail.iro.umontreal.ca/pipermail/gambit-list/2005-March/000168.htm...
Afficher les réponses par date
I get no problems here:
euler-70% vi crap.scm euler-71% gsc crap euler-72% gsi crap euler-73% gsi Gambit Version 4.0 beta 20
(load "crap")
"/export/users/lucier/crap.o1"
*** EOF again to exit euler-74% cat crap.scm (define (loop i) (if (zero? i) '() (cons i (loop (- i 1)))))
(loop 20000)
Do you have (declare (not interrupts-enabled))? If so, it will crash if you overflow the stack.
Brad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2-Apr-07, at 10:54 AM, Phil Dawes wrote:
Hi Gambit list,
I've started getting segmentation faults whenever I compile srfi-1.scm[1] and use it within my program and was wondering if it was to do with non-tail recursion.
I did a quick experiment and found that on my machine the following code compiled with gsc segfaults when i is just 20000 (it works fine interpreted):
(define (loop i) (if (zero? i) '() (cons i (loop (- i 1)))))
(loop 20000)
This seems quite limiting - is there flag I can tweak to improve this?
Many thanks,
Phil
It always amazes me when a bug that causes such "simple" code to fail goes unnoticed for so long. This bug is related to "context merging" at join points, which was changed in beta 21. The call (loop (- i 1)) is transformed to something like
(loop (if ... (##fx- i 1) (- i 1)))
Note that (##fx- i 1) is inlined and does not perform a function call, whereas (- i 1) performs a function call. The Gambit compiler generates a stack overflow for the call to (- i 1). For the call to loop the compiler thinks that it is unnecessary to check for stack overflows because it was checked on the call (- i 1). Of course this is incorrect when the "true" branch of the if is taken. Apply this patch to gsc/_front.scm to fix the problem:
1999c1999,2001 < (context-poll context1) - ---
(poll-merge (context-poll context1) (context-poll context2))
Thanks for the bug report!
Marc
Marc Feeley wrote:
[...] Apply this patch to gsc/_front.scm to fix the problem:
1999c1999,2001 < (context-poll context1)
(poll-merge (context-poll context1) (context-poll context2))
Thanks for the bug report!
You're welcome - thanks very much for the fix!
(fixed the testcase and the srfi-1 segfaults)
Cheers,
Phil
On Apr 2, 2007, at 2:44 PM, Marc Feeley wrote:
Apply this patch to gsc/_front.scm to fix the problem:
1999c1999,2001 < (context-poll context1)
(poll-merge (context-poll context1) (context-poll context2))
Marc:
Should we recompile the .scm files with the fixed compiler? If so, should we repeat? Do you think we get a fixed point? ;-)
Brad