Summary

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

Metadata

Attachments

Description

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.

Changes and comments

[2013-02-03 05:47:40 UTC] iraikov attached srfi-4-utils-test.scm (description=#f)

[2013-02-03 06:17:15 UTC] zbigniew wrote:

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

[2013-02-03 08:09:15 UTC] iraikov wrote:

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

[2013-02-05 02:20:50 UTC] iraikov wrote:

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?

[2013-02-15 16:13:53 UTC] felix changed status from new to closed

[2013-02-15 16:13:53 UTC] felix set resolution to invalid

[2013-02-15 16:13:53 UTC] felix wrote:

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.

[2013-02-17 05:23:55 UTC] iraikov wrote:

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.