#975 closed defect (invalid)
Segmentation fault when accessing/setting moderately large SRFI-4 vectors
Reported by: | Ivan Raikov | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | 4.9.0 |
Component: | compiler | Version: | 4.8.x |
Keywords: | Cc: | ||
Estimated difficulty: |
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.
Attachments (1)
Change History (6)
Changed 8 years ago by
Attachment: | srfi-4-utils-test.scm added |
---|
comment:1 follow-up: 2 Changed 8 years ago by
comment:2 Changed 8 years ago by
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
comment:3 Changed 8 years ago by
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?
comment:4 follow-up: 5 Changed 8 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
comment:5 Changed 8 years ago by
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.
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