Segmentation fault when accessing/setting moderately large SRFI-4 vectors

[Ivan Raikov]

The attached program runs properly when run under the interpreter, or when compiled with options -O0 -d2 but causes a segmentation fault when compiled with any optimization options. The program manipulates two f64vectors of 1 million elements, so its memory requirements should be well below the default maximum heap size of 2G. Any help is appreciated.

[Jim Ursetto]

I'm having problems reproducing this reliably, out of the builds below I got 3 crashes and 7 successes. These are not the most thorough choice of builds but it's what I had at hand. Maybe your best bet is to find a version that works and a version that doesn't (with the same compiler) and bisect it?

linux 32-bit
4.7.0.3 gcc crash
4.8.0.1 gcc crash

linux 64-bit
4.7.0.6 gcc success
4.7.0.6 clang success

os x 64-bit
4.7.0.6 gcc (LLVM) success
4.7.0.6 clang success
4.8.0 clang success
4.8.0.1 clang success
4.8.2 (master) gcc (LLVM) crash
4.8.2 (master) clang success

[Ivan Raikov]

If the size of the f64vectors is increased to 2 million elements, I can reproduce segmentation faults consistently on 64-bit Linux with Chicken 4.7.0, 4.7.4 and 4.8.0 compiled with gcc 4.7.2. The fact that you are seeing this in Chicken 4.7.0.3 seems to suggest that is not a new bug that appeared between 4.7.0 and 4.8.0.

Replying to zbigniew:

I'm having problems reproducing this reliably, out of the builds below I got 3 crashes and 7 successes. These are not the most thorough choice of builds but it's what I had at hand. Maybe your best bet is to find a version that works and a version that doesn't (with the same compiler) and bisect it?

linux 32-bit
4.7.0.3 gcc crash
4.8.0.1 gcc crash

linux 64-bit
4.7.0.6 gcc success
4.7.0.6 clang success

os x 64-bit
4.7.0.6 gcc (LLVM) success
4.7.0.6 clang success
4.8.0 clang success
4.8.0.1 clang success
4.8.2 (master) gcc (LLVM) crash
4.8.2 (master) clang success

[Ivan Raikov]

Running the program under gdb reveals that the segmentation fault is caused by stack overflow.
It appears that if gcc is passed option -O2 or -O3, the program terminates normally, regardless of csc optimization flags. Is it possible that Chicken-generated code relies on tail-call elimination performed by gcc?

[felix winkelmann]

Ivan,

No, chicken does not rely on TCO from the C compiler (that's the whole point of using cheney-on-the-mta). Chicken will also not magically make non-tail-recursive code tail-recursive:

--- ../srfi-4-utils-test.scm~	2013-02-15 16:00:54.953867621 +0100
+++ ../srfi-4-utils-test.scm	2013-02-15 16:07:40.085861499 +0100
@@ -46,8 +46,9 @@
               (vblit! a i q b k)
               (if (< j r)
                   (vblit! a j r b k))))
+      )
       b
-      ))
+      )
   )

I promise not to tell anybody about this.

[Ivan Raikov]

Hehe, I had quietly fixed my code, and I was waiting to see if somebody notices the slightly displaced paren here :-) For my penitence, I will implement 100 tail-recursive algorithms...

Replying to felix:

Ivan,

No, chicken does not rely on TCO from the C compiler (that's the whole point of using cheney-on-the-mta). Chicken will also not magically make non-tail-recursive code tail-recursive:

--- ../srfi-4-utils-test.scm~	2013-02-15 16:00:54.953867621 +0100
+++ ../srfi-4-utils-test.scm	2013-02-15 16:07:40.085861499 +0100
@@ -46,8 +46,9 @@
               (vblit! a i q b k)
               (if (< j r)
                   (vblit! a j r b k))))
+      )
       b
-      ))
+      )
   )

I promise not to tell anybody about this.