Unlike related procedures such as current-directory and path-normalize which do have typechecks, each of following produce SIGSEGV on non-string input e.g.:

(path-expand #f #f)
(path-extension #f)
(path-strip-extension #f)
(path-strip-directory #f)
(path-directory #f)
(path-strip-directory #f)

Example:

$ gsc
Gambit v4.7.0

(path-expand #f #f)
Segmentation fault (core dumped)

With the following 2 files :

PS: No file attachement?? GitHub sucks baaad

- - - - - ffi.scm - - - - -

(c-define (raise-error code) (int) void "raise_error" ""
(raise 'foo))

(define test-error
(c-lambda (char-string int) void
#<<end-of-c-code
raise_error(-1);
end-of-c-code
))

- - - - - test.scm - - - - -

(define (setup)
(with-exception-catcher
(lambda (exc)
(pp 'exception-catched)
(exit 1))
(lambda ()
(test-error "o:/spaceou" 0)
(exit))))

(setup)

- - - - - - - - - -

The following can reproduce the crash

gsc ffi
gsc

(load "ffi")
...
(load "test")
exception-catched
*** ERROR -- The system cannot find the file specified.
(test-error
'#<procedure #2>
'#(#((#<procedure #3 current-directory> . "d:\test\error") () ()) #(0) 0 0 (#<procedure #4 current-exception-handler>

I get this unbound variable exception where the variable should obviously be bound.

((lambda (#:g168)
     ((lambda (#:g169)
        ((lambda (#:g170)
           (#:g168 display #:g169 #:g170))
         '(1 2 3 4 5)))
      3))
 (lambda (f x y)
   (f (member x y)))) 

*** ERROR IN ##raise-unbound-global-exception -- Unbound variable: #:g168

Whereas the same expression with symbols that don't begin with #: works fine :

((lambda (var168)
     ((lambda (var169)
        ((lambda (var170)
           (var168 display var169 var170))
         '(1 2 3 4 5)))
      3))
 (lambda (f x y)
   (f (member x y)))) 

(3 4 5)

On Windows, after cloning Gambit and running 'make bootstrap' I am left with the following untracked files. I suggest they be added to .gitignore.

$ gst

On branch master

Untracked files:

(use "git add ..." to include in what will be committed)

gsc-boot.exe

libgambc.a

libgambcgsc.a

libgambcgsi.a

nothing added to commit but untracked files present (use "git add" to track)

Here's some code:

(define (interpolation-points x)
(define ip (G-L-inner-product x -1 1))
(define poly (nth 6 (make-orthogonal-polynomials ip x 5)))
(let* ((a (term-coeff (list-ref (Polynomial-terms poly) 0)))
(b (term-coeff (list-ref (Polynomial-terms poly) 1)))
(c (term-coeff (list-ref (Polynomial-terms poly) 2))))
(define points (map (lambda (r) (sqrt r)) (quadratic-solver a b c)))
(append! points (list 0
(* (car points) -1)
(* (cadr points) -1)))
points))

I'd say that this is incorrect, because the definition of poly depends on the value of ip.

However, the interpreter accepts it just fine. We have

(pp interpolation-points)
(lambda (x)
(letrec ((ip (G-L-inner-product x -1 1)) (poly (nth 6 (make-orthogonal-polynomials ip x 5))))
(let ((a (term-coeff (list-ref (Polynomial-terms poly) 0))))
(let ((b (term-coeff (list-ref (Polynomial-terms poly) 1))))
(let ((c (term-coeff (list-ref (Polynomial-terms poly) 2))))
(letrec ((points (map (lambda (r) (sqrt r)) (quadratic-solver a b c))))
(append! points (list 0 (* (car points) -1) (* (cadr points) -1)))
points))))))

Shouldn't gambit signal an error here?

Brad

firefly:~/programs/gambit/4.7.1/gambit/complex-functions> cat test-sinh.scm
(declare (standard-bindings)
(extended-bindings)
(block)
(not safe))

(pp (##flsinh 1.0))
firefly:/programs/gambit/4.7.1/gambit/complex-functions> gsi test-sinh.scm
1.1752011936438014
firefly:/programs/gambit/4.7.1/gambit/complex-functions> gsc test-sinh
firefly:~/programs/gambit/4.7.1/gambit/complex-functions> gsi test-sinh
Segmentation fault (core dumped)

Hi Marc!

Rarely I get an error that Gambit just stops, while eating up all the CPU core.

It's so rare that I don't consider it a problem, though I'd be happy to see it gone of course.

I believe 50% of the time it happens within 5 seconds after Gambit started and thread-start! was invoked 1-5 times.

I ran into this error now, saw it something like four times in 6mo.

This is on Gambit gsc 4.6.6 on AMD64, compiled from source with --enable-single-host and some more.

The Gambit session is running a couple of Gambit threads, absolutely nothing exotic going on.

Had it in a GDB session so could reliably "profile" the error, output from that GDB session below.

Saved the core file for later reference too.

It's in _thread.scm , and from what I can see it's in |##thread-effective-priority-downgrade!|'s definition.

What it looks like to me is that by some reason we've got a self-referencing btq-deq-next chain element, that
keeps it reiterating forever.

I base this on that ___r1 and ___r3 and ___r4 remain constant; I'd guess that ___r1 is thread, ___r3 is btq and ___r4 is leftmost.

Do you have any thought on what the issue might be, or any on how I can track this further?

Many thanks,
Mikael

_thread.scm, the rows where the freeze appears to be

 ;; (##thread-effective-priority-downgrade! thread) is called to
 ;; recompute the effective priority of a thread.  It is only called in
 ;; situations where the new effective priority is no more than the old
 ;; one.
 
 (define-prim (##thread-effective-priority-downgrade! thread)
 
   (##declare (not interrupts-enabled))
 
   (let ((floats (macro-thread-floats thread)))
 
     ;; save old effective priority for later
 
     (macro-temp-set!
      (macro-thread-floats (macro-run-queue))
      (macro-effective-priority floats))
 
     ;; compute the maximum of the boosted priority and the
     ;; effective priority of all the threads in blocked thread
     ;; queues (i.e. mutexes, condvars, etc) owned by the thread
 
     (macro-effective-priority-set!
      floats
      (macro-boosted-priority floats))
 
     (let loop ((btq (macro-btq-deq-next thread)))
       (if (##not (##eq? btq thread))                                              -- Looks sth like _thread.c:10452
         (let ((leftmost (macro-btq-leftmost btq)))                                --                         :10456
           (if (##not (##eq? leftmost btq))                                        --                         :10457
             (let ((leftmost-floats (macro-thread-floats leftmost)))
               (if (##flonum.< (macro-effective-priority floats)
                               (macro-effective-priority leftmost-floats))
                 (macro-effective-priority-set!
                  floats
                  (macro-effective-priority leftmost-floats)))))
           (loop (macro-btq-deq-next btq)))))






Gdb log from "profiling" the frozen gsc session, as we see it's stuck in a loop in _thread.c between rows 10451 and 10458 :


 Program received signal SIGINT, Interrupt.
 0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 10457      ___IF(___EQP(___R4,___R3))
 (gdb) bt
 #0  0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 #1  0x00000000005086fb in ___call (nargs=0, proc=13386241, stack_marker=8829493553) at setup.c:1860
 #2  0x000000000050a31d in ___setup (setup_params=0x7f7fffff0460) at setup.c:3024
 #3  0x000000000052d8ca in ___main (linker=0x505ddc <____20___gsc__(___global_state_struct*)>) at main.c:711
 #4  0x000000000051a9fc in ___main_char (argc=5, argv=0x7f7fffff06a8, linker=0x505ddc   <____20___gsc__(___global_state_struct*)>, script_line=0x0) at os_base.c:413
 #5  0x0000000000505e16 in main (argc=5, argv=0x7f7fffff06a8) at _gsc_.c:13627
 (gdb) cont
 Continuing.
 
 Program received signal SIGINT, Interrupt.
 0x000000000075a8f2 in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10452
 10452      ___IF(___EQP(___R3,___R1))
 (gdb) bt
 #0  0x000000000075a8f2 in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10452
 #1  0x00000000005086fb in ___call (nargs=0, proc=13386241, stack_marker=8829493553) at setup.c:1860
 #2  0x000000000050a31d in ___setup (setup_params=0x7f7fffff0460) at setup.c:3024
 #3  0x000000000052d8ca in ___main (linker=0x505ddc <____20___gsc__(___global_state_struct*)>) at main.c:711
 #4  0x000000000051a9fc in ___main_char (argc=5, argv=0x7f7fffff06a8, linker=0x505ddc  <____20___gsc__(___global_state_struct*)>, script_line=0x0) at os_base.c:413
 #5  0x0000000000505e16 in main (argc=5, argv=0x7f7fffff06a8) at _gsc_.c:13627
 (gdb) cont
 Continuing.
 
 Program received signal SIGINT, Interrupt.
 0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 10457      ___IF(___EQP(___R4,___R3))
 (gdb) bt
 #0  0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 #1  0x00000000005086fb in ___call (nargs=0, proc=13386241, stack_marker=8829493553) at setup.c:1860
 #2  0x000000000050a31d in ___setup (setup_params=0x7f7fffff0460) at setup.c:3024
 #3  0x000000000052d8ca in ___main (linker=0x505ddc <____20___gsc__(___global_state_struct*)>) at main.c:711
 #4  0x000000000051a9fc in ___main_char (argc=5, argv=0x7f7fffff06a8, linker=0x505ddc  <____20___gsc__(___global_state_struct*)>, script_line=0x0) at os_base.c:413
 #5  0x0000000000505e16 in main (argc=5, argv=0x7f7fffff06a8) at _gsc_.c:13627
 (gdb) ^CQuit
 (gdb) cont
 Continuing.
 
 Program received signal SIGINT, Interrupt.
 ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10451
 10451      ___SET_R3(___VECTORREF(___R3,___FIX(1L)))
 (gdb) bt
 #0  ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10451
 #1  0x00000000005086fb in ___call (nargs=0, proc=13386241, stack_marker=8829493553) at setup.c:1860
 #2  0x000000000050a31d in ___setup (setup_params=0x7f7fffff0460) at setup.c:3024
 #3  0x000000000052d8ca in ___main (linker=0x505ddc <____20___gsc__(___global_state_struct*)>) at main.c:711
 #4  0x000000000051a9fc in ___main_char (argc=5, argv=0x7f7fffff06a8, linker=0x505ddc  <____20___gsc__(___global_state_struct*)>, script_line=0x0) at os_base.c:413
 #5  0x0000000000505e16 in main (argc=5, argv=0x7f7fffff06a8) at _gsc_.c:13627
 
 
 
 Program received signal SIGINT, Interrupt.
 ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10456
 10456      ___SET_R4(___VECTORREF(___R3,___FIX(6L)))
 (gdb) bt
 #0  ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10456
 #1  0x00000000005086fb in ___call (nargs=0, proc=13386241, stack_marker=8829493553) at setup.c:1860
 #2  0x000000000050a31d in ___setup (setup_params=0x7f7fffff0460) at setup.c:3024
 #3  0x000000000052d8ca in ___main (linker=0x505ddc <____20___gsc__(___global_state_struct*)>) at main.c:711
 #4  0x000000000051a9fc in ___main_char (argc=5, argv=0x7f7fffff06a8, linker=0x505ddc  <____20___gsc__(___global_state_struct*)>, script_line=0x0) at os_base.c:413
 #5  0x0000000000505e16 in main (argc=5, argv=0x7f7fffff06a8) at _gsc_.c:13627
 (gdb) cont
 Continuing.
 
 Program received signal SIGINT, Interrupt.
 0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 10457      ___IF(___EQP(___R4,___R3))
 (gdb) bt
 #0  0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 #1  0x00000000005086fb in ___call (nargs=0, proc=13386241, stack_marker=8829493553) at setup.c:1860
 #2  0x000000000050a31d in ___setup (setup_params=0x7f7fffff0460) at setup.c:3024
 #3  0x000000000052d8ca in ___main (linker=0x505ddc <____20___gsc__(___global_state_struct*)>) at main.c:711
 #4  0x000000000051a9fc in ___main_char (argc=5, argv=0x7f7fffff06a8, linker=0x505ddc  <____20___gsc__(___global_state_struct*)>, script_line=0x0) at os_base.c:413
 #5  0x0000000000505e16 in main (argc=5, argv=0x7f7fffff06a8) at _gsc_.c:13627
 (gdb) cont
 Continuing.
 
 Program received signal SIGINT, Interrupt.
 0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 10457      ___IF(___EQP(___R4,___R3))
 (gdb) bt
 #0  0x000000000075a90a in ___H__20___thread (_(short *)=0x11c47e0) at _thread.c:10457
 #1  0x00000000005086fb in ___call (nargs=0, proc=13386241, stack_marker=8829493553) at setup.c:1860
 #2  0x000000000050a31d in ___setup (setup_params=0x7f7fffff0460) at setup.c:3024
 #3  0x000000000052d8ca in ___main (linker=0x505ddc <____20___gsc__(___global_state_struct*)>) at main.c:711
 #4  0x000000000051a9fc in ___main_char (argc=5, argv=0x7f7fffff06a8, linker=0x505ddc  <____20___gsc__(___global_state_struct*)>, script_line=0x0) at os_base.c:413
 #5  0x0000000000505e16 in main (argc=5, argv=0x7f7fffff06a8) at _gsc_.c:13627




Well, since that was about a traversal over a structure, let's make some profiling of what the ___r1/3/4 variable is, so we get a clue of how the traversal goes!


 (gdb) info locals
 ___r4 = 9052459177
 ___F64V1 = 9.9999999999999995e-07
 ___r1 = 9051204137
 ___F64V2 = 0
 _(char *) = 14328769
 ___temp = 9052462209
 ___hp = 0x21b91bbc8
 _(float,  *) = 0x208306628
 _(long double, ) = 14327969
 ___r2 = 9051204361
 ___F64V3 = 0.02
 ___start = 14314721
 ___r3 = 9052459177
 ___F64V4 = 0.02
 
 next:
 
 ___r4 = 9052459177
 ___F64V1 = 9.9999999999999995e-07
 ___r1 = 9051204137
 ___F64V2 = 0
 _(char *) = 14328769
 ___temp = 9052462209
 ___hp = 0x21b91bbc8
 _(float,  *) = 0x208306628
 _(long double, ) = 14327969
 ___r2 = 9051204361
 ___F64V3 = 0.02
 ___start = 14314721
 ___r3 = 9052459177
 ___F64V4 = 0.02
 
 
 next:
 
 ___r4 = 9052459177
 ___F64V1 = 9.9999999999999995e-07
 ___r1 = 9051204137
 ___F64V2 = 0
 _(char *) = 14328769
 ___temp = 9052462209
 ___hp = 0x21b91bbc8
 _(float,  *) = 0x208306628
 _(long double, ) = 14327969
 ___r2 = 9051204361
 ___F64V3 = 0.02
 ___start = 14314721
 ___r3 = 9052459177
 ___F64V4 = 0.02
 
 
 next:
 
 ___r4 = 9052459177
 ___F64V1 = 9.9999999999999995e-07
 ___r1 = 9051204137
 ___F64V2 = 0
 _(char *) = 14328769
 ___temp = 9052462209
 ___hp = 0x21b91bbc8
 _(float,  *) = 0x208306628
 _(long double, ) = 14327969
 ___r2 = 9051204361
 ___F64V3 = 0.02
 ___start = 14314721
 ___r3 = 9052459177
 ___F64V4 = 0.02
 
 next:
 
 ___r4 = 9052459177
 ___F64V1 = 9.9999999999999995e-07
 ___r1 = 9051204137
 ___F64V2 = 0
 _(char *) = 14328769
 ___temp = 9052462209
 ___hp = 0x21b91bbc8
 _(float,  *) = 0x208306628
 _(long double, ) = 14327969
 ___r2 = 9051204361
 ___F64V3 = 0.02
 ___start = 14314721
 ___r3 = 9052459177
 ___F64V4 = 0.02
 











The rows it's stuck at, in _thread.c .




(the following was copied from _thread.c of Gambit 4.6.2,
it looks like it's equivalent with 4.6.6 at least on these locations, so should be fine)


       #undef ___PH_PROC
       #define ___PH_PROC ___H__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_
       #undef ___PH_LBL0
       #define ___PH_LBL0 414
       #undef ___PD_ALL
       #define ___PD_ALL ___D_FP ___D_R0 ___D_R1 ___D_R2 ___D_R3 ___D_R4 ___D_F64(___F64V1) ___D_F64(___F64V2) \

       #undef ___PR_ALL
       #define ___PR_ALL ___R_FP ___R_R0 ___R_R1 ___R_R2 ___R_R3 ___R_R4
       #undef ___PW_ALL
       #define ___PW_ALL ___W_FP ___W_R0 ___W_R1 ___W_R2 ___W_R3 ___W_R4
       ___BEGIN_P_COD
       ___BEGIN_P_HLBL
       ___DEF_P_HLBL_INTRO
       ___DEF_P_HLBL(___L0__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
       ___DEF_P_HLBL(___L1__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
       ___END_P_HLBL
       ___BEGIN_P_SW
       ___DEF_SLBL(0,___L0__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___IF_NARGS_EQ(1,___NOTHING)
          ___WRONG_NARGS(0,1,0,0)
       ___DEF_GLBL(___L__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___SET_R2(___UNCHECKEDSTRUCTUREREF(___R1,___FIX(14L),___SUB(22),___FAL))
          ___SET_F64(___F64V1,___F64VECTORREF(___R2,___FIX(6L)))
          ___SET_R4(___RUNQUEUE)
          ___SET_R4(___UNCHECKEDSTRUCTUREREF(___R4,___FIX(14L),___SUB(22),___FAL))
          ___F64VECTORSET(___R4,___FIX(2L),___F64V1)
          ___SET_F64(___F64V2,___F64VECTORREF(___R2,___FIX(5L)))
          ___F64VECTORSET(___R2,___FIX(6L),___F64V2)
          ___SET_STK(1,___R0)
          ___SET_STK(2,___R1)
          ___SET_STK(3,___R2)
          ___SET_R3(___VECTORREF(___R1,___FIX(1L)))
          ___SET_R0(___LBL(1))
          ___ADJFP(8)
          ___IF(___EQP(___R3,___R1))
          ___GOTO(___L6__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___END_IF
          ___GOTO(___L4__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
       ___DEF_GLBL(___L2__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___SET_R4(___UNCHECKEDSTRUCTUREREF(___R4,___FIX(14L),___SUB(22),___FAL))
          ___SET_F64(___F64V1,___F64VECTORREF(___R4,___FIX(6L)))
          ___SET_F64(___F64V2,___F64VECTORREF(___R2,___FIX(6L)))
          ___ADJFP(2)
          ___IF(___F64LT(___F64V2,___F64V1))
          ___GOTO(___L5__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___END_IF
          ___ADJFP(-2)
       ___DEF_GLBL(___L3__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
 10451:    ___SET_R3(___VECTORREF(___R3,___FIX(1L)))
 10452:    ___IF(___EQP(___R3,___R1))
          ___GOTO(___L6__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___END_IF
       ___DEF_GLBL(___L4__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
 10456:    ___SET_R4(___VECTORREF(___R3,___FIX(6L)))
 10457:    ___IF(___EQP(___R4,___R3))
 10458:    ___GOTO(___L3__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___END_IF
          ___GOTO(___L2__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
       ___DEF_GLBL(___L5__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___SET_F64(___F64V1,___F64VECTORREF(___R4,___FIX(6L)))
          ___F64VECTORSET(___R2,___FIX(6L),___F64V1)
          ___ADJFP(-2)
          ___GOTO(___L3__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
       ___DEF_GLBL(___L6__23__23_thread_2d_effective_2d_priority_2d_downgrade_21_)
          ___SET_R1(___VOID)
          ___JUMPPRM(___NOTHING,___R0)

This is on latest binaries for OS X 64 bit, Gambit 4.7.2, fresh install

davids-air:Chapter_17 dave$ gsi fib.scm
55davids-air:Chapter_17 dave$ gsc fib.scm
clang: error: unknown argument: '-fschedule-insns2' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
*** ERROR IN ##main -- C compilation or link failed while compiling "fib.scm"

davids-air:Chapter_17 dave$ clang --version
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

fib.scm:

(define (fib n)
(if (< n 3)
1
(+ (fib (- n 1)) (fib (- n 2)))))

(print (fib 10))

By some reason, the thread-call-result mutex in ##thread-call does not get a corresponding ##btq-abandon! call for it, leading to memory leak.

This can be worked around by adding (##btq-abandon! result-mutex) to ##thread-call just right before its final expression (macro-mutex-specific result-mutex) (= row 1230).

I guess though that there is a cleaner solution to this.

Reproduction script:

(##gc-report-set! #t) (##set-live-percent! 80)
(define capturing-thread (thread-start! (make-thread (lambda ()
                                                       (let loop ()
                                                         (##thread-continuation-capture (current-thread))
                                                         (loop))))))
(thread-sleep! 5)
(thread-terminate! capturing-thread)
(##gc)

Output:

> (##gc-report-set! #t) (##set-live-percent! 80)
> > (define capturing-thread (thread-start! (make-thread (lambda ()
                                                       (let loop ()
                                                         (##thread-continuation-capture (current-thread))
                                                         (loop))))))
> (thread-sleep! 15)
*** GC: 169 ms, 19.9M alloc, 19.6M heap, 8.00M live (41% 8255144+131164)
*** GC: 320 ms, 31.4M alloc, 22.6M heap, 17.7M live (78% 18410120+131164)
*** GC: 404 ms, 36.4M alloc, 27.9M heap, 21.8M live (78% 22745040+131164)
*** GC: 531 ms, 42.4M alloc, 34.4M heap, 26.9M live (78% 28058760+131164)
*** GC: 694 ms, 49.9M alloc, 41.9M heap, 33.2M live (79% 34686736+131164)
*** GC: 864 ms, 58.6M alloc, 50.6M heap, 40.5M live (80% 42297456+131164)
*** GC: 1059 ms, 68.7M alloc, 61.6M heap, 49.0M live (80% 51219824+131164)
*** GC: 1313 ms, 81.3M alloc, 74.7M heap, 59.5M live (80% 62277520+131164)
*** GC: 1614 ms, 96.5M alloc, 90.9M heap, 72.2M live (79% 75602000+131164)
*** GC: 2039 ms, 115M alloc, 110M heap, 87.8M live (80% 91985064+131164)
*** GC: 2460 ms, 137M alloc, 133M heap, 107M live (80% 111557712+131164)
*** GC: 3140 ms, 164M alloc, 162M heap, 129M live (80% 135105392+131164)
> (thread-terminate! capturing-thread)
> (##gc)
*** GC: 28 ms, 164M alloc, 19.6M heap, 748K live (4% 634856+131164)

thread-terminate! makes ##thread-end! which does ##btq-abandon! on all btq-deq:s , this is why it releases the memory.

With the file

http://www.math.purdue.edu/~lucier/r5rstest-haschoo.scm

the following happens:

firefly:~/programs/gambit/gambit/complex-functions> gsi -:s
Gambit v4.7.0

(load "r5rstest-haschoo.scm")
*** ERROR IN map -- invalid syntax quote
1> ,b
0 map
1 #<procedure #2> "/usr/local/Gambit-C/v4.7.0/lib/syntax-case.scm"@7848:1 (map (lambda (%%e1388) (%%chi433 %%e1...
2 map
3 #<procedure #3> "/usr/local/Gambit-C/v4.7.0/lib/syntax-case.scm"@7848:1 (map (lambda (%%e1388) (%%chi433 %%e1...
4 map
5 #<procedure #4> "/usr/local/Gambit-C/v4.7.0/lib/syntax-case.scm"@8822:1 (%%chi-frobs430 (append %%inits1454 %...
6 #<procedure #5> "/usr/local/Gambit-C/v4.7.0/lib/syntax-case.scm"@11804:1 (%%chi-body438 (cons %%e11715 %%e217...
7 ##call-with-values
8 map
9 map
...
885 | _eval|
886 ##load
887 ##load
888 (interaction) (console)@1:1 (load "r5rstest-haschoo.scm")
1>

I have no idea where the error might be.

When compiling multiple scheme files with -link option, the link file will have the name of the very last scheme file. E.g.

       gsc -link 1.scm 2.scm 3.scm 4.scm

will generate

 1.c
 2.c
 3.c
 4.c
 4_.c

Currently I have to do some gymnastics in the makefile to figure out the name of the very last file given to gsc so it can be passed into the rest of compilation process.
It would be nice to have a command line option to explicitely specify the name (and output) location of the link file.

To use the .info files with emacs it is necessary to add the info file to the global info directory. The data to do this automatically is present in the .info file. However 'make install' does not invoke 'install-info' to actually do this.

On debian I used:

sudo ginstall-info --section=Scheme --keep-old /usr/local/Gambit-C/current/info/gambit-c.info /usr/share/info/dir

to properly install the directory entries in the global dir file under the 'Scheme' label which is where I keep all my scheme related info files.

(BTW: To uninstall add the --delete option to the command)

It would be nice for us emacs folks if something like this would be added to the makefile. Not being a heavy makefile user I better refrain from suggesting an actual patch myself :-)

The test case below worked fine in 4.6.6 on MSVC, and started erring on switch to 4.7.0 on MSVC.

With all tested MSVC versions (2005, 2010 & partial 2012 per below), Gambit compilation and loading works well, as long as sticking to C mode (i.e. without passing cc-options: "-TP").

When switching to C++ mode, execution of loaded compiled Scheme code still works, however any FFI call arguments turn out garbled on the C side, and returning values from C to Scheme leads to a crash, possibly with a wait first:

testc.scm

(print "Loaded.\n")
(c-declare "#include ")
(define (test-scheme-code in) (+ in in))
(define test-pass-int
        (c-lambda (int) void "printf(\"Got int %i .\\n\",___arg1);"))
(define test-return-int (c-lambda () int "___result = 5;"))

Interaction:

> (compile-file "testc.scm")
> (load "testc.o1")
Loaded.
> (test-pass-int 5)
Got int 5.
> (test-return-int)
5
> (compile-file "testc.scm" cc-options: "-TP")
> (load "testc.o2")
Loaded.
> (test-pass-int 5)
Got int 37617689.
> (test-pass-int 4)
Got int 37617688.
> (test-return-int)                            ; => SIGSEGV

test-pass-int's output is constant between invocations and loads. However, if restarting gambit and switching load order so test.o2 first and test.o1 then, then the invalid transformation is another one, though constant between invocations and loads then too.

This was tried and gave the same result on:

• MSVC 2010 Express-compiled gsc and testc.o*
  (gsc compiled with misc\vcexpress2008.bat)
• MSVC 2005 Express-compiled gsc and testc.o*
  (gsc compiled with misc\vcexpress.bat)
• MSVC 2012-compiled gsc (the prebuilt one on the web site) and MSVC 2010-compiled testc.o*

Unfortunately, I have not had the opportunity to compile testc.o* with MSVC 2012 too, however given the context of the eerror, I expect the error to be present also there.
     (Just in case there would be some other Gambit binary than gsc used in the test above, that could be causing the crash due to compiler version inconsistency - that one would then have been compiled with MSVC 2012 while gsc was compiled with 2010/2005.
     Also, if gambit.h would be compiler version-dependent that could cause this error, however as far as I'm aware, gambit.h should be constant between MSVC versions.
     Actually, the gambit.h generated by the misc*.bat scripts does not work, so how to generate a gambit.h for use in MSVC and its absence of a configure script, is a bit of an enigma to me currently - feel free to clarify this!)

Multi-line strings don't work on windows when compiled or run from a file.

Assuming the file multilinewinbug.scm has following content:

(display "This is a multi\
        line string")

When trying to run or compile it, an error occurs.

D:\multilinewinbug>gsi multilinewinbug.scm
*** ERROR IN "multilinewinbug.scm"@1.10 -- Invalid escaped character: #\return

D:\multilinewinbug>gsc multilinewinbug.scm
*** ERROR IN "multilinewinbug.scm"@1.10 -- Invalid escaped character: #\return

Evaluating the same code directly in gsi works as expected.

When specifying the -o with -link, one C file goes into current folder, the other into the folder provided by -o.

Expected behaviour: Both C files should be placed in the bam folder.

    $ ls
    bam  t.scm
    $ ls bam
    $ /usr/local/Gambit-C/bin/gsc -o bam -link -cc-options "-o bam" t.scm
    $ ls
    bam  t.c  t.scm
    $ ls bam
    t_.c
    $ 

GSC crashes while compiling some code of mine. It was compiled with CC=clang CXX=clang++ CFLAGS="-g3 -march=core2 -msse4.1" ./configure --enable-inline-jumps --enable-gcc-opts --enable-multiple-versions --enable-poll. Version 4.6.7 compiled with the same options does not crash.

I was not able to create a minimal test case yet but, nevertheless, this is what I get from the core file with GDB:

#0  0x00000001083d21dc in ___H__23__23_readtable_2d_parse_2d_keyword (___ps=0x1089f4200) at _io.c:59250
59250      ___SET_R4(___STRINGREF(___STK(0),___R4))
gdb$ bt
#0  0x00000001083d21dc in ___H__23__23_readtable_2d_parse_2d_keyword (___ps=0x1089f4200) at _io.c:59250
#1  0x000000010828ace4 in ___call (nargs=<value temporarily unavailable, due to optimizations>, proc=<value temporarily unavailable, due to optimizations>, stack_marker=<value temporarily unavailable, due to optimizations>) at setup.c:1864
Previous frame inner to this frame (gdb could not unwind past this frame)
Current language:  auto; currently minimal
gdb$ bt full
#0  0x00000001083d21dc in ___H__23__23_readtable_2d_parse_2d_keyword (___ps=0x1089f4200) at _io.c:59250
    ___r3 = 0x108663c
    ___r0 = 0x1086ede01
    ___pc = <value temporarily unavailable, due to optimizations>
    ___r4 = 0x108663c
    ___r1 = <value temporarily unavailable, due to optimizations>
    ___fp = <value temporarily unavailable, due to optimizations>
    ___r2 = #1  0x000000010828ace4 in ___call (nargs=<value temporarily unavailable, due to optimizations>, proc=<value temporarily unavailable, due to optimizations>, stack_marker=<value temporarily unavailable, due to optimizations>) at setup.c:1864
    ___pc = 0x108663c
    ___jbuf = {
  buf = {0x5797b818, 0x7fff, 0x863b8f1, 0x1, 0x5797b760, 0x7fff, 0x8295620, 0x1, 0x828ae90, 0x1, 0x81405321, 0x7fcb, 0x8295670, 0x1, 0x828ac6b, 0x1, 0x1, 0x0, 0x1fa0, 0x37f, 0x0, 0xffffffff, 0x4, 0x1, 0x863b8f1, 0x1, 0x828d78c, 0x1, 0x81403bf1, 0x7fcb, 0x863b851, 0x1, 0x5797b8b0, 0x7fff, 0x8293b41, 0x1, 0x863b851}
}
    ___jbuf = {
  buf = {0x5797b818, 0x7fff, 0x863b8f1, 0x1, 0x5797b760, 0x7fff, 0x8295620, 0x1, 0x828ae90, 0x1, 0x81405321, 0x7fcb, 0x8295670, 0x1, 0x828ac6b, 0x1, 0x1, 0x0, 0x1fa0, 0x37f, 0x0, 0xffffffff, 0x4, 0x1, 0x863b8f1, 0x1, 0x828d78c, 0x1, 0x81403bf1, 0x7fcb, 0x863b851, 0x1, 0x5797b8b0, 0x7fff, 0x8293b41, 0x1, 0x863b851}
}
    ___jbuf = {
  buf = {0x5797b818, 0x7fff, 0x863b8f1, 0x1, 0x5797b760, 0x7fff, 0x8295620, 0x1, 0x828ae90, 0x1, 0x81405321, 0x7fcb, 0x8295670, 0x1, 0x828ac6b, 0x1, 0x1, 0x0, 0x1fa0, 0x37f, 0x0, 0xffffffff, 0x4, 0x1, 0x863b8f1, 0x1, 0x828d78c, 0x1, 0x81403bf1, 0x7fcb, 0x863b851, 0x1, 0x5797b8b0, 0x7fff, 0x8293b41, 0x1, 0x863b851}
}
    ___jbuf = {
  buf = {0x5797b818, 0x7fff, 0x863b8f1, 0x1, 0x5797b760, 0x7fff, 0x8295620, 0x1, 0x828ae90, 0x1, 0x81405321, 0x7fcb, 0x8295670, 0x1, 0x828ac6b, 0x1, 0x1, 0x0, 0x1fa0, 0x37f, 0x0, 0xffffffff, 0x4, 0x1, 0x863b8f1, 0x1, 0x828d78c, 0x1, 0x81403bf1, 0x7fcb, 0x863b851, 0x1, 0x5797b8b0, 0x7fff, 0x8293b41, 0x1, 0x863b851}
}
    ___jbuf = {
  buf = {0x5797b818, 0x7fff, 0x863b8f1, 0x1, 0x5797b760, 0x7fff, 0x8295620, 0x1, 0x828ae90, 0x1, 0x81405321, 0x7fcb, 0x8295670, 0x1, 0x828ac6b, 0x1, 0x1, 0x0, 0x1fa0, 0x37f, 0x0, 0xffffffff, 0x4, 0x1, 0x863b8f1, 0x1, 0x828d78c, 0x1, 0x81403bf1, 0x7fcb, 0x863b851, 0x1, 0x5797b8b0, 0x7fff, 0x8293b41, 0x1, 0x863b851}
}
    ___jbuf = {
  buf = {0x5797b818, 0x7fff, 0x863b8f1, 0x1, 0x5797b760, 0x7fff, 0x8295620, 0x1, 0x828ae90, 0x1, 0x81405321, 0x7fcb, 0x8295670, 0x1, 0x828ac6b, 0x1, 0x1, 0x0, 0x1fa0, 0x37f, 0x0, 0xffffffff, 0x4, 0x1, 0x863b8f1, 0x1, 0x828d78c, 0x1, 0x81403bf1, 0x7fcb, 0x863b851, 0x1, 0x5797b8b0, 0x7fff, 0x8293b41, 0x1, 0x863b851}
}
    ___old_catcher = <value temporarily unavailable, due to optimizations>
    ___r2 = <value temporarily unavailable, due to optimizations>
    ___fp = <value temporarily unavailable, due to optimizations>
    ___r3 = <value temporarily unavailable, due to optimizations>
    ___r1 = <value temporarily unavailable, due to optimizations>

While writing some macros, I found that the interpreter and the compiler handle quasiquote in a different way.

Here is some small code which shows the difference:

;;; test.scm
(define-macro (testm x)
  `(lambda () `(a b . ,,x)))

(define (test x)
  (testm x))

$ gsc test.scm
$ gsi
Gambit v4.7.1

(load "test.scm")
"test.scm"
((test 1)) ; execute interpreted code
(a b . 1)
(load "test.o1")
"test.o1"
((test 1)) ; execute compiled code
(a b unquote x)

I expect that the interpreted and the compiled code both produce '(a b . 1). The result obtained by the compiled code deviates from my expectation. I think this is specific to the unquote appearing after the dot in the dotted list. Since if one defines instead

(define (testm x)
  `(lambda () `(a b ,,x)))

then ((test 1)) produces '(a b 1) both in interpreted and in compiled code.

I've written a scheme bootstrapper that replaces the bash+scheme functionality in syntax-case-build & syntax-case-expand-file.

From testing, I can determine that aside from whitespace, which is stripped in the former bash implementation, bootstrap output is identical:

bash-3.2$ pwd
/Volumes/Data/Users/matthastie/scratch/scheme/gambit/lib
bash-3.2$ ./syntax-case-build
-> copying psyntax73.pp to psyntax0-at-load.scm with rtem/ctem set to '(l)
-> using psyntax0-at-load.scm to expand psyntax73.ss to psyntax1-at-load.scm
-> using psyntax1-at-load.scm to expand psyntax73.ss to psyntax2-at-load.scm
-> using psyntax2-at-load.scm to expand psyntax73.ss to syntax-case.scm
-> comparing last two expansions (there should be no differences)
============================================
============================================
bash-3.2$ cp syntax-case.scm syntax-case.orig
bash-3.2$ cp /tmp/boot-sc ./syntax-case-build 
bash-3.2$ ./syntax-case-build
bash-3.2$ diff -w syntax-case.scm syntax-case.orig 
bash-3.2$ 

Patch is as follows:

From c5b211c7d3480c2c780d1cad3d6ad2fcdac0b97b Mon Sep 17 00:00:00 2001
From: Matt Hastie <[email protected]>
Date: Mon, 28 Oct 2013 22:02:25 -0700
Subject: [PATCH] bashless syntax-case bootstrap

---
 lib/syntax-case-build       | 132 +++++++++++++++++++++++++-------------------
 lib/syntax-case-expand-file |  33 -----------
 2 files changed, 76 insertions(+), 89 deletions(-)
 delete mode 100755 lib/syntax-case-expand-file

diff --git a/lib/syntax-case-build b/lib/syntax-case-build
index 715cede..52a3fbc 100755
--- a/lib/syntax-case-build
+++ b/lib/syntax-case-build
@@ -1,56 +1,76 @@
-#! /bin/sh
-
-# File: "syntax-case-build", Time-stamp: <2007-04-03 20:32:05 feeley>
-
-# Copyright (c) 2007 by Marc Feeley, All Rights Reserved.
-
-PSYNTAX=psyntax73
-
-add_prelude()
-{
-  cat syntax-case-prelude.scm $1 > $2
-}
-
-create_final()
-{
-  cat syntax-case-prelude.scm $1 syntax-case-postlude.scm | sed -e "s/^ *//g" > $2
-}
-
-modify_for_load_time()
-{
-  tr '\n' '�' < $1 | sed "s/'(e)\(� *\)'(e)/'(l)\1'(l)/" | sed "s/'(E)\(� *\)'(E)/'(L)\1'(L)/" | tr '�' '\n' > $2
-}
-
-rm -f psyntax1.scm psyntax2.scm psyntax3.scm psyntax0-at-load.pp psyntax1-at-load.pp psyntax2-at-load.pp psyntax0-at-load.scm psyntax1-at-load.scm psyntax2-at-load.scm syntax-case.scm
-
-echo "-> copying $PSYNTAX.pp to psyntax0-at-load.scm with rtem/ctem set to '(l)"
-
-modify_for_load_time $PSYNTAX.pp psyntax0-at-load.pp
-add_prelude psyntax0-at-load.pp psyntax0-at-load.scm
-
-echo "-> using psyntax0-at-load.scm to expand $PSYNTAX.ss to psyntax1-at-load.scm"
-
-./syntax-case-expand-file psyntax0-at-load.scm $PSYNTAX.ss psyntax1.scm
-modify_for_load_time psyntax1.scm psyntax1-at-load.pp
-add_prelude psyntax1-at-load.pp psyntax1-at-load.scm
-
-echo "-> using psyntax1-at-load.scm to expand $PSYNTAX.ss to psyntax2-at-load.scm"
-
-./syntax-case-expand-file psyntax1-at-load.scm $PSYNTAX.ss psyntax2.scm
-modify_for_load_time psyntax2.scm psyntax2-at-load.pp
-add_prelude psyntax2-at-load.pp psyntax2-at-load.scm
-
-echo "-> using psyntax2-at-load.scm to expand $PSYNTAX.ss to syntax-case.scm"
-
-./syntax-case-expand-file psyntax2-at-load.scm $PSYNTAX.ss psyntax3.scm
-create_final psyntax3.scm syntax-case.scm
-
-echo "-> comparing last two expansions (there should be no differences)"
-
-echo ============================================
-
-diff psyntax2.scm psyntax3.scm
-
-echo ============================================
-
-rm -f psyntax1.scm psyntax2.scm psyntax3.scm psyntax0-at-load.pp psyntax1-at-load.pp psyntax2-at-load.pp psyntax0-at-load.scm psyntax1-at-load.scm psyntax2-at-load.scm
+#! ../gsi/gsi -:=..
+
+;; eval maintains its own namespace configuration associated with the
+;; interaction-cte. the content of syntax-case-prelude.scm needs to be
+;; evaluated so that $sc-put-cte definitions emitted by psyntax to
+;; eval share the namespace context of syntax-case-prelude. this
+;; allows definitions to access functions andmap, ormap, gensym? which
+;; are in the sc# namespace.
+
+(eval
+ '(include "syntax-case-prelude.scm"))
+
+(define psyntaxpp
+  "psyntax73.pp")
+
+(define psyntaxss
+  "psyntax73.ss")
+
+(define make-read-expander
+  (lambda (expander)
+    (lambda (input)
+      ;; begin is prepended to simulate top-level expansion. this
+      ;; practice bypasses the "invalid context for definition" error
+      ;; that otherwise occurs without its presence.
+      (##desourcify (expander `(begin ,@(read-all input)))))))
+
+;;
+;; eval the bootstrapping psyntax.pp
+;;
+(eval
+ (call-with-input-file psyntaxpp
+   (lambda (input)
+     `(begin ,@(read-all input)))))
+
+;; psyntax.pp ships with ctem and rtem assigned to '(E), which emits
+;; visit content to eval, and not the expanded output. this is an odd
+;; choice, considering that psyntax.pp itself appends the $sc-put-cte
+;; definitions after the revisit content. psyntaxpp can thus not
+;; bootstrap itself with its default settings!
+
+;; to accomodate this, we bootstrap psyntax.ss with '(E) values of
+;; ctem and rtem, and then use the resultant expander to re-expand
+;; psyntax.ss with ctem and rtem with respective values of '(L C) and
+;; '(L) to generate the final syntax-case.scm.
+
+(eval
+ (call-with-input-file psyntaxss
+   (make-read-expander sc-expand)))
+
+(define syntax-case
+  "syntax-case.scm")
+
+(call-with-output-file syntax-case
+  (lambda (output)
+    
+    (define psyntaxss "psyntax73.ss")
+    (define prelude "syntax-case-prelude.scm")
+    (define postlude "syntax-case-postlude.scm")
+
+    (define read-as-string
+      (lambda (input)
+        (read-line input #!eof)))
+    
+    (print port: output
+           (call-with-input-file prelude
+             read-as-string))
+    
+    (eval '(set! gensym-count 0))
+
+    (pretty-print
+     (call-with-input-file psyntaxss
+       (make-read-expander sc-compile-expand)) output)
+
+    (print port: output
+           (call-with-input-file postlude
+             read-as-string))))
diff --git a/lib/syntax-case-expand-file b/lib/syntax-case-expand-file
deleted file mode 100755
index d7dad2c..0000000
--- a/lib/syntax-case-expand-file
+++ /dev/null
@@ -1,33 +0,0 @@
-#! ../gsi/gsi -:=..
-
-;;; File: "syntax-case-expand-file", Time-stamp: <2007-05-27 23:09:04 feeley>
-
-;;; Copyright (c) 2007 by Marc Feeley, All Rights Reserved.
-
-;;;============================================================================
-
-(define expand-file
-  (lambda (filename-in filename-out)
-    (let* ((exprs
-            (cons 'begin
-                  (with-input-from-file
-                      filename-in
-                    (lambda ()
-                      (let loop ((rev-lst '()))
-                        (let ((x (read)))
-                          (if (eof-object? x)
-                              (reverse rev-lst)
-                              (loop (cons x rev-lst)))))))))
-           (expanded
-            (sc-expand exprs)))
-      (with-output-to-file
-          filename-out
-        (lambda ()
-          (pretty-print
-           (sc#annotation-stripped expanded)))))))
-
-(eval `(##include ,(cadr (command-line))))
-
-(apply expand-file (cddr (command-line)))
-
-;;;============================================================================
-- 
1.8.3.4 (Apple Git-47)

After pulling the latest Gambit on Windows, I now get a strange regression in TCP/IP where code that has always worked flawlessly now fails in some cases.

I will update this issue as I get more precise info on how to reproduce the problem.

This regression was introduced between commits

commit b43ef13
Merge: 2fa887a f91ed15
Author: Marc Feeley [email protected]
Date: Wed Sep 12 11:35:23 2012 -0400

Merge branch 'master' of github.com:feeley/gambit
and the latest

commit 0089927
Author: Marc Feeley [email protected]
Date: Sun May 5 22:52:56 2013 -0400

Fix C++ type error with size_t not equal to ___SIZE_T

config.sub and config.guess haven't been updated since 2002, this makes it very difficult to package this for debian, since this won't build on all arches

After pulling the latest Gambit on Windows, I now get random Heap Overflow crashes that do not end up in Gambit's debugger but simply exit the process.

This regression was introduced between commits

commit b43ef13
Merge: 2fa887a f91ed15
Author: Marc Feeley [email protected]
Date: Wed Sep 12 11:35:23 2012 -0400

Merge branch 'master' of github.com:feeley/gambit

and the latest

commit 0089927
Author: Marc Feeley [email protected]
Date: Sun May 5 22:52:56 2013 -0400

Fix C++ type error with size_t not equal to ___SIZE_T

Please see this gist for an example:
https://gist.github.com/caolan/4e877150800c1b3ba2e5

A (declare) to enforce this would do the job.

A table with test: eq? where the key is a closure and thus needs to guaranteedly be unique should be a perfectly valid usecase.

Noted that currently in compiled code (lambda () ...) not guaranteedly returns a unique closure object in certain circumstances: if a closure closes over no variables, or Gambit optimizes away all closed over variables so no variables are closed over that way, then it does not generate a unique closure.

This was quite surprising to me as my best understanding of R5RS spec (here & here) is that eq? should work on procedures:

"Each procedure created as the result of evaluating a lambda expression is (conceptually) tagged with a storage location, in order to make eqv? and eq? work on procedures (see section 6.1)."

Perhaps the wording could have been even more precise.

I acknowledge this Gambit optimization is really useful many times. Though there should be a way to disable it as it wouldn't be a reliable coding strategy to need to outsmart the optimizer for correct function.

Example:

$ gsc
Gambit v4.6.6

> (let loop () (define x (lambda () 'myvalue)) (print x "\n") (loop))
#<procedure #2 x>
#<procedure #3 x>
#<procedure #4 x>
#<procedure #5 x>
[...]
[ctrl+c],q

$ echo (let loop () (define x (lambda () 'myvalue)) (print x "\n") (loop)) > test.scm
$ gsc
Gambit v4.6.6

> (compile-file "test.scm")
"test.o1"
> (load "test.o1")
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
#<procedure #2>
[...]

This

(let loop ((v 0)) (define x (lambda () v 'myvalue)) (print x "\n") (loop 1))

gives the same behavior. Note that the lambda closes over v, though the compiler optimizes it away.

Neither 

(let loop ((v 0)) (define x (lambda (z) (declare (not optimize-dead-local-variables)) v 'myvalue)) (print x "\n") (loop 1))

works, which may appear a bit surprising!


Here's a hack around the optimizer though:

(let loop ((v 0)) (define x (lambda (z) (case z ((never-happens) v) (else 'myvalue)))) (print x "\n") (loop 1))

This issue is based on some unexpected behavior that showed up and was explored in issue 17 (https://github.com/feeley/gambit/issues/17):

On OpenBSD 5.2 AMD64, doing a complete recompile of Gambit fails when having --enable-debug set, only.

The failure consists of the "gsc-boot -c _thread.scm" call SIGSEGV:ing.

The ordinary way of running into the issue is:

git clone git://github.com/feeley/gambit.git; cd gambit; ./configure --enable-single-host --enable-debug; make bootstrap -j8; make pull; make

However, it can with benefit be reduced to

git clone git://github.com/feeley/gambit.git; cd gambit; ./configure --enable-single-host --enable-debug; make bootstrap -j8; cd lib; ../gsc/gsc -c _thread.scm

The problem seems to have something to do with memory management, because

a) All -:m >=10224 makes the problem go away, while the problem persists with any lower -:m , i.e.

../gsc/gsc -:m10224 -e "(##gc-report-set! #t)(compile-file-to-target "_thread.scm")" => success
../gsc/gsc -:m10223 -e "(##gc-report-set! #t)(compile-file-to-target "_thread.scm")" => failure

The sigsegv happens on or after the second GC. It happens within ~0.3 seconds of compile-file-to-target execution.

b) Making some random addition or removal of a define-prim in _thread.scm tends to make the compilation error go away.

The problem has been found with both G++ and GCC 4.6.3, and with G++ 4.2.1.

Now that the problem was found on GCC too, that does not use libstdc++, and on G++ 4.2.1, which uses the OS-bundled libstdc++ library version, I don't think the problem should arise from a strictly Gambit-external source.
Though, it may be that OpenBSD's internal security mechanisms of which there are many (see for instance http://www.openbsd.org/papers/rp2007-slides.pdf ), brings a problem to the surface that can't be seen on other platforms.

Coincidentally, on Debian Etch i386 with G++ 4.1.2, doing a complete recompile of this Gambit version fails also (by "git clone git://github.com/feeley/gambit.git; cd gambit; ./configure --enable-single-host --enable-debug; make bootstrap -j2; make pull; make"), though at another place in the compile process; the "gsc -c _thread.scm" step does work there.

I'd be curious to learn to know how this plays out on other platforms that are somewhere in between on the security scale, like FreeBSD or Mac OS X.

Another thing to check is how many Gambit versions/commits back this problem exists.

Trying to compile the latest gambit from git ec54dd4 on Linux x86_64, Ubuntu 12.04LTS, gcc 4.6.3.

I tried a variety of options, but when I invoke gsi or gsc, it fails at startup with this error message:
./gsi/gsi: symbol lookup error: ./gsi/gsi: undefined symbol: __S_here_2d_strings_2d_allowed_3f

Am I doing something wrong or is there indeed a missing symbol?

cd $HOME/src/gambit &&
: git clean -xfd &&
: ./configure
--prefix=$HOME/local/stow/gambit
--enable-single-host
--enable-c-opt=-O6
--enable-gcc-opts
--enable-cplusplus
--enable-shared
--enable-inline-jumps
--enable-char-size=1
--enable-multiple-versions
--enable-thread-system=posix
--enable-multiple-vms
--enable-multiple-threaded-vms
&&
make -l4 from-scratch &&
make check &&
make install ;
exit

On Windows, after cloning Gambit and running 'make' I am left with the following modified files.

$ gst

On branch master

Changes not staged for commit:

(use "git add ..." to update what will be committed)

(use "git checkout -- ..." to discard changes in working directory)

modified: gsc/_asm.c

modified: gsc/_assert.c

modified: gsc/_back.c

modified: gsc/_codegen.c

modified: gsc/_env.c

modified: gsc/_front.c

modified: gsc/_gambcgsc.c

modified: gsc/_gsc.c

modified: gsc/gsc.c

modified: gsc/_gsclib.c

modified: gsc/_gvm.c

modified: gsc/_host.c

modified: gsc/_parms.c

modified: gsc/_prims.c

modified: gsc/_ptree1.c

modified: gsc/_ptree2.c

modified: gsc/_source.c

modified: gsc/_t-c-1.c

modified: gsc/_t-c-2.c

modified: gsc/_t-c-3.c

modified: gsc/_t-univ.c

modified: gsc/_utils.c

modified: gsc/_x86.c

modified: gsi/_gambcgsi.c

modified: gsi/_gsi.c

modified: gsi/gsi.c

modified: gsi/_gsilib.c

modified: lib/_eval.c

modified: lib/_gambc.c

modified: lib/_io.c

modified: lib/_kernel.c

modified: lib/_nonstd.c

modified: lib/_num.c

modified: lib/_repl.c

modified: lib/_std.c

modified: lib/_system.c

modified: lib/_thread.c

Hello Marc,
starting with commit b29a2b6 (Change "define-prim" ...) gsc/igsc.scm doesn't work
anymore for me. It seems that when define-prim gets expanded later
c#target.prim-info is still #f, i.e. not initialised.

Cheers, Tara

It happens when there is plenty of heap space left, and the tcp-client input-output-port is perfectly available on the heap.

This was something unexpected from Gambit so I thought I should write it up here.

I'm working on with a memory leak bug currently and am trying to find what trigs it, directly or indirectly, so mentioned it now as it perhaps could be related.

If you have any particular idea of what may cause this feel free to share, thanks

How to reproduce:

$ gsc
Gambit v4.6.9

> (make-will '(1 2) (lambda (v) (print "GC:ed\n")))
#<will #2>
> (will-execute! #2)
GC:ed
> 1
1
> 2
2
> 3
3
> (##gc)
> #2
#<will #2>
> 1
1
> 2
2
> 3
3
> 4
4
> 5
5
> (##gc)
> #2
#<will #2>
>

(The 1 2 3 evaluations above were done to clear any object reference that the REPL's # ## ### slots could be having to the will.)

Mechanism:

• I create a will with a testator set (it's a port).
  That the testator is such is verified by a debug printout.

  (I understand that this implies addition of the will to ___ps->nonexecutable_wills internally straight away)

• I invoke will-execute! on the will.
  Thus its testator value switches to #f.

• There are no other object references to the will. Thus, this would be a suitable time for the will to GC!

  Resolving its referencing objects confirms there's no other object references to it.

  The resolve confirms that the will is still in the wills list.

  (Also the resolve shows that Gambit's ___ps->r / GVM_REGS has a reference to the will, though I understand that that should be an effect of the REPL introspection work only and completely transitory.)

  determine_will_executability does not have the behavior that if the testator is not a memory allocated object (which it is now - #f is indeed not a memory allocated object) it would mark the will as executable and thus dispatch it this way.

  At the same time, the garbage collector treats representation of a will in ___ps->nonexecutable_wills as a strong variable reference.

  Thus, we've got a state where the will is never garbage collected.

Please let me know if there is something that I did not get.

I get the following:

heine:~/programs/gambiteer/gambit/tests> ./run-unit-tests.scm
../gsi/gsi: symbol lookup error: ../gsi/gsi: undefined symbol: ___gstate0

I looked at the script but didn't find the problem.

Brad

gsc/gsc -:=. -exe pidigits2-gambit
[Media-Mac-mini-3:gambit/4.6.9/gambit] lucier% !time
time ./pidigits2-gambit > /dev/null
(time (digits 10000))
15358 ms real time
15356 ms cpu time (15278 user, 78 system)
6497 collections accounting for 2315 ms real time (2300 user, 30 system)
12173629752 bytes allocated
1217 minor faults
no major faults
15.281u 0.086s 0:15.37 99.9% 0+0k 0+0io 0pf+0w
[Media-Mac-mini-3:gambit/4.6.9/gambit] lucier% time ./pidigits2-gambit -:m100000 > /dev/null
(time (digits 10000))
25284 ms real time
25188 ms cpu time (14396 user, 10792 system)
118 collections accounting for 3748 ms real time (277 user, 3453 system)
12173329704 bytes allocated
2190082 minor faults
no major faults
14.401u 10.836s 0:25.33 99.6% 0+0k 0+0io 0pf+0w
[Media-Mac-mini-3:gambit/4.6.9/gambit] lucier% gsc/gsc -v
v4.6.9 20130501174650 i386-apple-darwin10.8.0 "./configure 'CC=/pkgs/gcc-4.8.0/bin/gcc -march=native -fschedule-insns -frename-registers' '--enable-single-host' '--enable-multiple-versions'"

And that's with only a 100MB heap.

Here's the code:

[Media-Mac-mini-3:gambit/4.6.9/gambit] lucier% cat pidigits2-gambit.scm
(declare (standard-bindings)
(extended-bindings)
(block)
(not safe)
(mostly-fixnum))

(define-macro (when test . body)
`(if ,test
(begin
,@Body)))

(define-macro (unless test . body)
`(if (not ,test)
(begin
,@Body)))

(define (digits n)
(let ((i 0)
(_x0 1)
(_x1 0)
(_x2 1))

(define (extract-digit n)
  (let ((r (quotient (+ (* _x0 n) _x1) _x2)))
    ;; (pp (list 'quotient: r))
    r))

(let loop ((k 0))
  (if (> _x0 _x1)
      (let* ((k (+ k 1))
             (y2 (+ (* k 2) 1)))
        (set! _x1 (+ (* _x1 y2)
                     (* _x0 (* y2 2))))
        (set! _x0 (* _x0 k))
        (set! _x2 (* _x2 y2))
        (loop k))
      (let ((d (extract-digit 3)))
        (if (not (= d (extract-digit 4)))
            (let* ((k (+ k 1))
                   (y2 (+ (* k 2) 1)))
              ;; (pp 'crap)
              (set! _x1 (+ (* _x1 y2)
                           (* _x0 (* y2 2))))
              (set! _x0 (* _x0 k))
              (set! _x2 (* _x2 y2))
              (loop k))
            (begin
              (display d)
              (set! i (+ i 1))
              (let ((m (modulo i 10)))
                (when (zero? m)
                      (map display (list #\tab #\: i #\newline)))
                (if (< i n)
                    (begin
                      (set! _x1 (* 10 (- _x1 (* _x2 d))))
                      (set! _x0 (* _x0 10))
                      (loop k))
                    (unless (zero? m)
                            (map display (list (make-string (- 10 m) #\space)
                                               #\tab
                                               #\:
                                               n
                                               #\newline))))))))))))

(time (digits 10000))

It would be reasonable to believe that doing a (close-port) on an output-port-timeout would either succeed or lead to an IO exception.

The mechanics of close-port is that if there is still output data to drain to the port, close-port will do a write for that data and then close the port. This write operation (done in ##byte-wbuf-drain-no-reset) has these logics:

               (let ((continue?
                      (or (##wait-for-io!
                           (macro-device-port-wdevice-condvar port)
                           (macro-port-wtimeout port))
                          ((macro-port-wtimeout-thunk port)))))

i.e. if there's an error it will be considered a write timeout error.

That this is the case would need consideration of the programmer, not to ever do

    (output-port-timeout-set! port timeout (lambda () (close-port port) #f))

but rather

    (output-port-timeout-set! port timeout (let ((close-time? #t))
                                             (lambda ()
                                               (if close-time? (begin (set! close-time? #f)
                                                                      (close-port port)))
                                               #f))

On a test machine with Gambit started with gsc -:dar,t8,l30,m20000,-n,tn,f8 , the first code example, per below, causes 6599 output-timeout recursions and then an IO error.

Is this a bug or a feature?

Worked around it for now this way anyhow.

 Output:

 Write timeout #1.
 [...]
 Write timeout #6599.
 IO error.
 230400
 >

 Code:

 (define (generate-output-timeout-recursion)

   (define console-output-port (current-output-port))

   (define timeout-seconds 1)

   (let\* (

```
      ; Set up a server,
      (server (open-tcp-server '(port-number: 1234)))

      ; Open a client connection to the server,
      (client (open-tcp-client '(port-number: 1234)))

      ; And establish this connection on the server side.
      (connection (read server))

      )

  ; Setup IO and
  (port-io-exception-handler-set! connection (lambda (e)
                                              (print port: console-output-port "IO error.\n")
                                              (force-output console-output-port 1)
                                              #f))

 ; write timeout exception handling.
 (output-port-timeout-set! connection
                           timeout-seconds
                           (let ((count 0))
                             (lambda ()
                               (set! count (+ count 1))
                               (print port: console-output-port "Write timeout #" count ".\n")
                               (force-output console-output-port 1)
                               (close-port connection)
                               #f)))

 ; Write data to the port. Much enough for it to jam the OS' network buffer,
 ; so that we will get a write timeout.
 (write-subu8vector (make-u8vector 4096000) 0 4096000 connection)

 ; Then, close the connection from the client's side
 ; (close-port client)

 ; And then ask Gambit to flush the written data on the now closed connection.
 ; (force-output connection 1)

 ))
```

Assume a struct with a default release function:

(c-declare "struct point { int x; int y; };")
(c-define-type struct-point (struct "point"))

(define make-point 
  (c-lambda (int int) struct-point 
    "struct point p; 
      p.x = ___arg1; 
      p.y = ___arg2;
      ___result = p;"))

The function call (make-point x y) will trigger an unexpected segmentation fault.

An equivalent example without an inline c-lambda expression is working.

(c-declare #<<END
struct point { int x; int y; };

struct point make_point(int x, int y) {
    struct point p;
    p.x = x;
    p.y = y;
    return p;   
}
END

(define make-point 
  (c-lambda (int int) struct-point "make_point")
)

This bug is occuring with gambit's version v4.7.0.

This is on OS X 10.8.4.

Configure line:

CC=/usr/bin/clang CXX=/usr/bin/clang++ CFLAGS="-march=core2 -g3" ./configure --prefix=/usr/local/Gambit-C --enable-inline-jumps --enable-gcc-opts --enable-poll --enable-multiple-versions --enable-debug

Crash site:

libsystem_kernel.dylib`__ioctl:
   0x7fff915ced00:  movl   $33554486, %eax
   0x7fff915ced05:  movq   %rcx, %r10
   0x7fff915ced08:  syscall
-> 0x7fff915ced0a:  jae    0x7fff915ced11            ; __ioctl + 17
   0x7fff915ced0c:  jmpq   0x7fff915d04c8            ; cerror
   0x7fff915ced11:  ret
   0x7fff915ced12:  nop
   0x7fff915ced13:  nop

Stack trace:

* thread #1: tid = 0x1c03, 0x00007fff915ced0a libsystem_kernel.dylib`__ioctl + 10, stop reason = signal SIGTTOU
    frame #0: 0x00007fff915ced0a libsystem_kernel.dylib`__ioctl + 10
    frame #1: 0x00007fff915ce183 libsystem_kernel.dylib`ioctl + 159
    frame #2: 0x00007fff917cbfbd libsystem_c.dylib`tcsetattr + 74
    frame #3: 0x000000010002560e gsi`___device_tty_mode_update(self=0x0000000101016e00, current=1) + 1694 at os_tty.c:529
    frame #4: 0x0000000100024bc6 gsi`___device_tty_mode_restore(self=0x0000000101016e00, remove=0) + 198 at os_tty.c:608
    frame #5: 0x00000001000248d3 gsi`___device_tty_force_open(self=0x0000000101016e00) + 259 at os_tty.c:915
    frame #6: 0x000000010002ae59 gsi`___device_tty_write_raw_virt(self=0x0000000101016e00, buf=0x0000000100b2bdd8, len=1, len_done=0x00007fff5fbfedec) + 57 at os_tty.c:7692
    frame #7: 0x000000010003069e gsi`___device_stream_write(self=0x0000000101016e00, buf=0x0000000100b2bdd8, len=1, len_done=0x00007fff5fbfedec) + 62 at os_io.c:2087
    frame #8: 0x00000001000327d4 gsi`___os_device_stream_write(dev=4304429777, buffer=4306681297, lo=0, hi=4) + 116 at os_io.c:7761
    frame #9: 0x000000010006ebda gsi`___H__20___kernel_23_32(___ps=0x0000000100671c98) + 442 at _kernel.c:16918
    frame #10: 0x0000000100008ccc gsi`trampoline(___ps=0x0000000100671c98) + 92 at setup.c:1805
    frame #11: 0x0000000100008bde gsi`___call(nargs=0, proc=4299925745, stack_marker=4304421729) + 558 at setup.c:1889
    frame #12: 0x000000010000ae4a gsi`___setup(setup_params=0x00007fff5fbff910) + 7418 at setup.c:3075
    frame #13: 0x0000000100006df4 gsi`___main(linker=0x0000000100005840) + 5460 at main.c:713
    frame #14: 0x00000001000202f6 gsi`___main_char(argc=1, argv=0x00007fff5fbffaf8, linker=0x0000000100005840, script_line=0x0000000000000000) + 150 at os_base.c:413
    frame #15: 0x0000000100005893 gsi`main(argc=1, argv=0x00007fff5fbffaf8) + 51 at _gsi_.c:8861
    frame #16: 0x00007fff916f87e1 libdyld.dylib`start + 1

The console file is full of lines like this:

*** OS ERROR AT "os_tty.c"@1063.1 -- errno=35 (Resource temporarily unavailable)
read len=128
*** OS ERROR AT "os_tty.c"@1063.1 -- errno=35 (Resource temporarily unavailable)
read len=128
*** OS ERROR AT "os_tty.c"@1063.1 -- errno=35 (Resource temporarily unavailable)
read len=128
*** OS ERROR AT "os_tty.c"@1063.1 -- errno=35 (Resource temporarily unavailable)
read len=128
*** OS ERROR AT "os_tty.c"@1063.1 -- errno=35 (Resource temporarily unavailable)
read len=128
*** OS ERROR AT "os_tty.c"@1063.1 -- errno=35 (Resource temporarily unavailable)
read len=128
*** OS ERROR AT "os_tty.c"@1063.1 -- errno=35 (Resource temporarily unavailable)
read len=128

Opening a bidirectional process (that actually reads input) gets stuck in ##make-device-port-from-single-device

Example:

> gsi
Gambit v4.6.9

> (open-process "ls")
#<input-output-port #2 (process "ls")>
> (close-port #2)
> (open-process "base64")
;; STUCK
  C-c C-c*** INTERRUPTED IN ##make-device-port-from-single-device
1> ,b
0  ##make-device-port-from-single-device 
1  ##open-process-generic  
2  (interaction)           (console)@3:1           (open-process "base64")

This used to work fine until very recently.

Would you like to add the configuration script "AX_PTHREAD" to your build specification?

To reproduce, start gsi and type or paste the following in the REPL prompt:

'(a b λ (c λ (d e f λ λ

then start closing the parentheses. The highlight of the matching parentheses is off to the left of where it should be.

I should have thought that if a and b are strings of digits then

ia/b

would be processed by string->number as (exact->inexact "a/b"), but it is not:

(string->number "#i1/0")
+inf.0

It appears to be processed as

(/ (exact->inexact "a") (exact->inexact "b"))

yet this is invalid:

1.0/2.0
*** ERROR IN ##raise-unbound-global-exception -- Unbound variable: 1.0/2.0

I don't like the behavior of (string->number "#i1/0").

Gambiteer

Compiling latest Gambit (a184058) on OBSD 5.2 with ./configure --enable-cplusplus --enable-debug --enable-single-host fails per below.

For a workaround hack, changing lib/_kernel.c:14773 to

 ___vm_stats ((long*) &minflt, (long*) &majflt);

works.

$ make
making all in include
major=`echo v4.6.9 | sed -e "s/v//g" -e "s/\.[^.]*\.[^.]*//g"`;  minor=`echo v4.6.9 | sed -e "s/v[^.]*\.//g" -e "s/\.[^.]*//g"`;  revision=`echo v4.6.9 | sed -e "s/v[^.]*\.[^.]*\.//g" -e "s///g"`;  version_num=`eval expr "\( 100000 \\* $major \) + \( 1000 \\* $minor \) + $revision"`;  echo "#error \"The version indicated in ___VERSION is not supported by gambit.h\"" > gambit-not$version_num.h;  echo "#error \"You are probably compiling C code generated by a Gambit compiler earlier or later than v4.6.9\"" >> gambit-not$version_num.h;  echo "#error \"___VERSION will be set to $version_num to reduce other errors\"" >> gambit-not$version_num.h;  echo "#undef ___VERSION" >> gambit-not$version_num.h;  echo "#define ___VERSION $version_num" >> gambit-not$version_num.h;  echo "#include \"gambit.h\"" >> gambit-not$version_num.h
making all in lib
../gsc-boot -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c  -check _io.scm
../gsc-boot -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c  -check _num.scm
../gsc-boot -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c  -check _std.scm
../gsc-boot -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c  -check _kernel.scm
g++ -Wno-unused -Wno-write-strings -g -fno-trapping-math -fno-strict-aliasing -fwrapv -fPIC -fno-common -mieee-fp  -I"../include" -c -o "_kernel.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"amd64\"" -D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"openbsd5.2\"" -D___CONFIGURE_COMMAND="\"./configure '--enable-cplusplus' '--enable-debug' '--enable-single-host'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL _kernel.c -D___LIBRARY
_kernel.c: In function 'long int ___H__20___kernel(___processor_state)':
_kernel.c:14473:35: error: invalid conversion from 'long unsigned int*' to 'long int*' [-fpermissive]
os.h:1536:13: error:   initializing argument 1 of 'void ___vm_stats(long int*, long int*)' [-fpermissive]
_kernel.c:14473:35: error: invalid conversion from 'long unsigned int*' to 'long int*' [-fpermissive]
os.h:1536:13: error:   initializing argument 2 of 'void ___vm_stats(long int*, long int*)' [-fpermissive]
*** Error code 1

Stop in /tmp/gambit/lib (line 89 of /usr/share/mk/sys.mk).
*** Error code 1

Stop in /tmp/gambit (line 403 of makefile).

The following c-lambda makes a segfault on os x using clang

(define make-u8vector-still (c-lambda (int) scheme-object
 "int len = ___arg1; ___result = ___EXT(___alloc_scmobj)(___sU8VECTOR,len,___STILL);"))

The 4.6.5 tarball is set up with two git repos: http://dynamo.iro.umontreal.ca/~chjaeger/localwork/gambit.git and github. The first contains all the tagged releases but the second does not (and should be gambit.git, not Gambit.git)

For multi-homed network setups.

On all the Unixes, this is accomplished by http://www.openbsd.org/cgi-bin/man.cgi?query=bind&sektion=2 .

As I get it it's the same on Windows, http://msdn.microsoft.com/en-us/library/windows/desktop/ms737550(v=vs.85).aspx , they even included an invocation example at the bottom of that page to show

Examples:

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/ftp.c?annotate=1.82 row 214

https://github.com/poolpOrg/OpenSMTPD/blob/master/smtpd/ioev.c row 599

Any protocol or file format parser currently implemented in Gambit is producing a risk of heap overflow if they contain any reading of or parsing to arbitrary symbols given in the input data.

Current workaround is extremely heavy marshalling code and using strings instead, however important formats such as SXML contain symbols in its definition, making such marshalling an enormous workaround or impossible task to achieve depending on problem complexity, and undermining schemyness.

Understanding the current design where symbols don't GC may be because of minimalism or performance reasons and acknowledging that that is a top priority in Gambit, I humbly wish to suggest the introduction of a --enable-symbol-gc or similar configure option that switches this on.

(
As an extra bonus when symbols do GC, is that it will be possible to do some execution of untrusted code, even if within very extensive constraints only (currently running any untrusted code whatsoever is not viable as mitigating the symbol heap overflow risk requires at least in the direction of implementing a new Scheme environment atop Gambit).
)

Marc:

The program at the end works in 4.6.7, fails in 4.6.8 in the following environment:

Works:

frying-pan:~/lang/scheme/chudnovsky> gsi -v
v4.6.7 20130219214006 x86_64-unknown-linux-gnu "./configure '--enable-single-host' '--enable-shared' '--enable-multiple-versions'"

Doesn't work:

frying-pan:/lang/scheme/chudnovsky> gsi -v
v4.6.8 20130430024640 x86_64-unknown-linux-gnu "./configure '--enable-single-host' '--enable-shared' '--enable-multiple-versions'"
frying-pan:/lang/scheme/chudnovsky> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
frying-pan:/lang/scheme/chudnovsky> uname -a
Linux frying-pan 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
frying-pan:/lang/scheme/chudnovsky> gsi -e '(load "chud1.scm")'
| > (ch-split 0 7053)
| | > (ch-split 0 3526)

| | | | | | | |[13] > (ch-split 73 75)
| | | | | | | |[14] > (ch-split 73 74)
| | | | | | | |[14](28588119 4432769187497607168000 1153643848480497675)
| | | | | | | |[14] > Segmentation fault (core dumped)

Brad

;;; Program to use the chudnovsky formula to compute pi.
;;; Written by Bakul Shah.
;;; Changed by Bradley Lucier to use standard arithmetic operations
;;; available in Gambit Scheme.

(define ch-A 13591409)
(define ch-B 545140134)
(define ch-C 640320)
(define ch-C^3 (expt 640320 3))
(define ch-D 12)

(define (ch-split a b)
  (if (= 1 (- b a))
    (let ((g (* (- (* 6 b) 5) (- (* 2 b) 1) (- (* 6 b) 1))))
      (list g
            (floor (/ (* ch-C^3 (expt b 3)) 24))
            (* (expt -1 b) g (+ (* b ch-B) ch-A))))
    (let* ((mid (floor (/ (+ a b) 2)))
           (gpq1 (ch-split a mid))    ;<<<<====
           (gpq2 (ch-split mid b))    ;<<<<====
           (g1 (car gpq1)) (p1 (cadr gpq1)) (q1 (caddr gpq1))
           (g2 (car gpq2)) (p2 (cadr gpq2)) (q2 (caddr gpq2)))
      (list (* g1 g2)
            (* p1 p2)
            (+ (* q1 p2) (* q2 g1))))))

(define (pi digits)
      (let* ((num-terms (inexact->exact (floor (+ 2 (/ digits 14.181647462)))))
             (sqrt-C (integer-sqrt (* ch-C (expt 100 digits)))))
      (let* ((gpq (ch-split 0 num-terms))
             (g (car gpq)) (p (cadr gpq)) (q (caddr gpq)))
        (floor (/ (* p ch-C sqrt-C) (* ch-D (+ q (* p ch-A))))))))

(trace ch-split)
(pi 100000)

The macro FIXMULP in lib/gambit.h is defined as

define ___FIXMULP(x,y)(___EXPECT_FALSE(___FIXQUO((___temp=___FIXMUL(x,y)),y)!=(x))?___FAL:___temp)

So, note that it fails if y is zero, which is why there's a test for zero before using it in _num.scm, and in all code generated by the compiler.

I defined a function ##square that does what you think it should do, but I forgot to guard ##fixnum.? by a test for zero first, so things were crashing. It took me a while to find the problem.

Should we put the zero test right inside FIXMULP, if it's always needed anyway?

Brad

(declare (standard-bindings) (fixnum) (not safe))

(define (double1 x)
(+ ;; uses fixnum specific + (i.e. ##fx+)
x
x))

(define (double2 x)
((let () (declare (generic)) +) ;; uses generic +
x
x))

(double2 97650736685728012900) ; Should work
(double1 97650736685728012900) ; Should not work.

Currently the double2 call does not work too but + throws (Argument 1) FIXNUM expected.

Discussed on ML 2013-11-14.

Marc:

As you know, the C code generated by gsc violates C's strict aliasing rules in a few places (mainly in the bignum code and when working on the various subfields of a double-precision floating-point number), so, strictly speaking, passing gcc the flag -fno-strict-aliasing is necessary for correct compilation of the generated code.

it is unlikely that gcc's optimizer is smart enough to exploit the strict aliasing property to generate incorrect code when -fstrict-aliasing (the gcc default) is used, and in some circumstances enabling strict-aliasing speeds compiled code by 20% or more (although that depends on the speed of the memory subsystem compared to CPU speed, etc.).

So I recommend that a configure option --enable-strict-aliasing be added to the configure script, with --no-enable-strict-aliasing the default. People may want to use this option to generate faster, smaller code while being willing to risk the (small) chance that the C code will be miscompiled by gcc.

Brad

I would like to point out that identifiers like "___GAMBIT_H" and "___STAMP_YMD" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

I noticed that the Windows implementation of ___time_get_current_time uses GetSystemTime followed by SystemTimeToFileTime. The single function GetSystemTimeAsFileTime (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx) accomplishes the same task much more efficiently.

When I was building Fusion Sphere on ubuntu 14.04, something bad happened:

/usr/local/lib//libgambc.a(os_thread.o): in function ‘___thread_create’:
os_thread.c:(.text+0x4a): undefined reference to ‘pthread_create’
/usr/local/lib//libgambc.a(os_thread.o): in function ‘___thread_join’:
os_thread.c:(.text+0x8b): undefined reference to ‘pthread_join’
collect2: error: ld returned 1 exit status

Is it a bug? Any suggestions much appreciated.