Opened 12 years ago

Closed 10 years ago

#876 closed enhancement (wontfix)

csi segfaults immediately when running this code

Reported by: Christian Kellermann Owned by: felix winkelmann
Priority: minor Milestone:
Component: core tools Version: 4.7.x
Keywords: csi segfault master Cc:
Estimated difficulty:

Description (last modified by Christian Kellermann)

As found by uman on IRC the following works when compiled and crashes when interpreted:

(define (product-rec f a next b)
  (if (> a b) 1
      (* (f a) (product-rec f (next a) next b))))

(define (estimate-pi n)
  (define (num-term k)
    (+ k (if (even? k) 2 1)))
  (define (denom-term k)
    (+ k (if (even? k) 1 2)))
  (* 4 (product-rec (lambda (k) (/ (num-term k) (denom-term k))) 1 add1 n)))

(print (estimate-pi 100000))

This crashes current master, on x64 linux, also 4.7.0 on 32bit x86 OpenBSD

Change History (9)

comment:1 Changed 12 years ago by Christian Kellermann

Description: modified (diff)

comment:2 Changed 12 years ago by Christian Kellermann

When I increase the process's ulimit of its stack to unlimited it produces an answer without crashing. The garbage collection output gave me the hint:

; loading 1_31.scm ...
[GC] level  1	gcs(minor)  38	gcs(major)  3
[GC] stack	0x000000008b1296d0	0x000000008b129540	0x000000008b2296d0
[GC]  from	0x000000009e17e010	0x000000009e24eec0	0x000000009e279b10	0x00000000000d0eb0
[GC]    to	0x000000009f313010	0x000000009f313010	0x000000009f40eb10 
[GC] 0 locatives (from 32)
[GC] level  1	gcs(minor)  19	gcs(major)  4
[GC] stack	0x000000008b1296d0	0x000000008b129590	0x000000008b2296d0
[GC]  from	0x000000009f313010	0x000000009f4099f0	0x000000009f40eb10	0x00000000000f69e0
[GC]    to	0x000000009e17e010	0x000000009e17e010	0x000000009e279b10 
[GC] 0 locatives (from 32)
[GC] (old) fromspace: 	start=0x000000009f313010, 	limit=0x000000009f40eb10
[GC] (old) tospace:   	start=0x000000009e17e010, 	limit=0x000000009e279b10
[GC] resized heap to 4123648 bytes
[GC] (new) fromspace: 	start=0x00000000a0265010, 	limit=0x00000000a045c610
[GC] (new) tospace:   	start=0x00000000a045d010, 	limit=0x00000000a0654610
[GC] level  1	gcs(minor)  2	gcs(major)  5
[GC] stack	0x000000008b1296d0	0x000000008b129510	0x000000008b2296d0
[GC]  from	0x00000000a0265010	0x00000000a0361510	0x00000000a045c610	0x000000009d5771c4
[GC]    to	0x00000000a045d010	0x00000000a045d010	0x00000000a0654610 
[GC] 0 locatives (from 32)
[GC] level  1	gcs(minor)  113	gcs(major)  6
[GC] stack	0x000000008b1296d0	0x000000008b129570	0x000000008b2296d0
[GC]  from	0x00000000a045d010	0x00000000a0630bf0	0x00000000a0654610	0x00000000001d3be0
[GC]    to	0x00000000a0265010	0x00000000a0265010	0x00000000a045c610 
[GC] 0 locatives (from 32)
[GC] level  1	gcs(minor)  16	gcs(major)  7
[GC] stack	0x000000008b1296d0	0x000000008b129540	0x000000008b2296d0
[GC]  from	0x00000000a0265010	0x00000000a0458e78	0x00000000a045c610	0x00000000001f3e68
[GC]    to	0x00000000a045d010	0x00000000a045d010	0x00000000a0654610 
[GC] 0 locatives (from 32)
[GC] (old) fromspace: 	start=0x00000000a0265010, 	limit=0x00000000a045c610
[GC] (old) tospace:   	start=0x00000000a045d010, 	limit=0x00000000a0654610
[GC] resized heap to 8247296 bytes
[GC] (new) fromspace: 	start=0x00000000a0655010, 	limit=0x00000000a0a43c10
[GC] (new) tospace:   	start=0x00000000a0265010, 	limit=0x00000000a0653c10
[GC] level  1	gcs(minor)  1	gcs(major)  8
[GC] stack	0x000000008b1296d0	0x000000008b1294f0	0x000000008b2296d0
[GC]  from	0x00000000a0655010	0x00000000a084ca80	0x00000000a0a43c10	0x0000000000000000
[GC]    to	0x00000000a0265010	0x00000000a0265010	0x00000000a0653c10 
[GC] 0 locatives (from 32)
[GC] level  1	gcs(minor)  227	gcs(major)  9
[GC] stack	0x000000008b1296d0	0x000000008b129570	0x000000008b2296d0
[GC]  from	0x00000000a0265010	0x00000000a060b8f0	0x00000000a0653c10	0x00000000003a68e0
[GC]    to	0x00000000a0655010	0x00000000a0655010	0x00000000a0a43c10 
[GC] 0 locatives (from 32)
[GC] level  1	gcs(minor)  32	gcs(major)  10
[GC] stack	0x000000008b1296d0	0x000000008b1295b0	0x000000008b2296d0
[GC]  from	0x00000000a0655010	0x00000000a0a39f50	0x00000000a0a43c10	0x00000000003e4f40
[GC]    to	0x00000000a0265010	0x00000000a0265010	0x00000000a0653c10 
[GC] 0 locatives (from 32)
[GC] level  1	gcs(minor)  4	gcs(major)  11
[GC] stack	0x000000008b1296d0	0x000000008b1295c0	0x000000008b2296d0
[GC]  from	0x00000000a0265010	0x00000000a0653678	0x00000000a0653c10	0x00000000003ee668
[GC]    to	0x00000000a0655010	0x00000000a0655010	0x00000000a0a43c10 
[GC] 0 locatives (from 32)
[GC] (old) fromspace: 	start=0x00000000a0265010, 	limit=0x00000000a0653c10
[GC] (old) tospace:   	start=0x00000000a0655010, 	limit=0x00000000a0a43c10
[GC] resized heap to 16494592 bytes
[GC] (new) fromspace: 	start=0x00000000a0a44010, 	limit=0x00000000a1221810
[GC] (new) tospace:   	start=0x00000000a0265010, 	limit=0x00000000a0a42810
[GC] level  1	gcs(minor)  0	gcs(major)  12
[GC] stack	0x000000008b1296d0	0x000000008b1295a0	0x000000008b2296d0
[GC]  from	0x00000000a0a44010	0x00000000a0e343f0	0x00000000a1221810	0x0000000000000018
[GC]    to	0x00000000a0265010	0x00000000a0265010	0x00000000a0a42810 
[GC] 0 locatives (from 32)
3.14160836127809

comment:3 Changed 12 years ago by felix winkelmann

Owner: set to felix winkelmann
Status: newassigned

This is a simple stack overflow. Normally this should not be a problem as chicken allocates activation frames on the heap, but the checks that test whether the nursery is full (and whether a minor GC is needed) are not generated in all compiled procedures - specifically: not in continuation procedures. As long as these call normal compiled code, the called procedures will perform the check. Here we have the situation that the called procedure is a "primitive" (the internal, manually written C code for *), which doesn't do a stack/nursery-check.
Emitting stack-checks in all procedures might be too costly. One option would be to add stack-checks in primitives, or wrap them in a thunk, or something. I have to ponder this.

comment:4 Changed 12 years ago by felix winkelmann

Milestone: 4.8.04.9.0

A patch to fix this (using a specific build-mode), at least in the interpreter, is currently pending. To avoid any last minute problems, I propose to postpone this patch until after the next release.

comment:5 Changed 12 years ago by felix winkelmann

Milestone: 4.9.0
Priority: majorminor
Type: defectchange request

comment:6 Changed 12 years ago by felix winkelmann

Type: change requestenhancement

comment:7 Changed 11 years ago by Christian Kellermann

Which patch is this? Can we include it now? My memory is a blurr wrt. this issue.

comment:8 Changed 11 years ago by sjamaan

comment:9 Changed 10 years ago by Christian Kellermann

Resolution: wontfix
Status: assignedclosed
Note: See TracTickets for help on using tickets.