segfault in symbolGC tests on openbsd 5.0 with 4.7.0.3-stability

[zbigniew]

Pekka Niiranen reports segfault in symbolGC tests on openbsd 5.0 with 4.7.0.3-st release. No further details at this time.

======================================== symbol-GC tests ...
../chicken symbolgc-tests.scm -output-file a.c -include-path ..
gcc a.c -o a.o -c  -fno-strict-aliasing -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES \
  -Os -fomit-frame-pointer -I.. -I"/usr/local/include/chicken"
rm a.c
gcc a.o -o a.out -L.. -L"/usr/local/lib"  -Wl,-R"/usr/local/lib" -lchicken -lm -lpthread
../libchicken.so: warning: strcpy() is almost always misused, please use strlcpy()
../libchicken.so: warning: sprintf() is often misused, please use snprintf()
../libchicken.so: warning: strcat() is almost always misused, please use strlcat()
rm a.o
starting with 1232 symbols
interning 10000 symbols ...
Segmentation fault (core dumped)
gmake[1]: *** [check] Error 139
gmake[1]: Leaving directory `/home/pekka/compile/chicken-4.7.0.3-st'
gmake: *** [check] Error 2

[ckeen]

Hm, my OpenBSD 5.0 fails on the ports test instead.

Procedures check on output ports being closed

write...OK
fprintf...OK
print-call-chain...OK
print-error-message...OK
print...OK
print*...OK
display...OK
terminal-port?...OK
newline...OK
write-char...OK
write-line...OK
write-u8vector...OK
port->fileno...FAIL [ 6 ]

Error: assertion failed: (eq? okay (condition-case (begin (print* (quote port->fileno) "...") (flush-output) (let ((output (port->fileno out))) (printf "FAIL [ ~S ]\n" output))) ((exn i/o file) (printf "OK\n") okay)))

Call history:

<eval> (memv688 (##core#quote i/o682) kvar686)
<eval> (memv688 (##core#quote file683) kvar686)
<eval> (printf680 "OK\n")
<eval> (list712 (quote713 okay711))
<eval> (eq?715 okay711 (condition-case716 (begin717 (print*718 (quote709 port->fileno) "...") (flush-output......
<eval> ((call-with-current-continuation735 (##core#lambda (k733) (with-exception-handler736 (##core#lambda ...
<eval> (call-with-current-continuation735 (##core#lambda (k733) (with-exception-handler736 (##core#lambda (......
<eval> (with-exception-handler736 (##core#lambda (exvar726) (k733 (##core#lambda () (##core#let ((kvar727 (......
<eval> (##sys#call-with-values (##core#lambda () (begin717 (print*718 (quote709 port->fileno) "...") (flush......
<eval> (print*718 (quote709 port->fileno) "...")
<eval> (flush-output719)
<eval> (port->fileno out)
<eval> (printf721 "FAIL [ ~S ]\n" output720)
<eval> (k733 (##core#lambda () (##sys#apply ##sys#values args734)))
<eval> (##sys#apply ##sys#values args734)
<eval> (##sys#error "assertion failed" (##core#quote (eq? okay (condition-case (begin (print* (quote port->...... <--

[zbigniew]

Unrelated issue, already fixed in https://github.com/ursetto/chicken-core-stability/commit/6097b12c1bd3e8425b9ca0119e58765f1f781847

You have to check out stability HEAD, a new version has not been tagged yet

[ckeen]

Ah, a better version information would have helped!

I have tried the latest master and cannot reproduce the reported issue on OpenBSD 5.0 x86 32 bit

[ckeen]

Replying to ckeen:

Ah, a better version information would have helped!

I have tried the latest master and cannot reproduce the reported issue on OpenBSD 5.0 x86 32 bit

That should read latest HEAD of the stability branch of course, namely 3effbbdfcd30851142ddaf372203afc76e85b49d

[sjamaan]

This was most likely fixed in 38ca6fd52b7d54c9c2de1698bb984bf7fe3f673f. If it still fails, please reopen.

[zmyrgel]

I get this segfault again on chicken 4.7.0.6. Tested with OpenBSD 5.1 (amd64) and OpenBSD-current (amd64).

======================================== symbol-GC tests ...
../chicken symbolgc-tests.scm -output-file a.c -include-path ..
gcc a.c -o a.o -c -fno-strict-aliasing -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -Os -fomit-frame-pointer -I.. -I"/usr/local/include/chicken"
rm a.c
gcc a.o -o a.out -L.. -L"/usr/local/lib" -Wl,-R"/usr/local/lib" -lchicken -lm -pthread
../libchicken.so: warning: strcpy() is almost always misused, please use strlcpy()
../libchicken.so: warning: strcat() is almost always misused, please use strlcat()
../libchicken.so: warning: sprintf() is often misused, please use snprintf()
rm a.o
starting with 1233 symbols
interning 10000 symbols ...
Segmentation fault (core dumped)
gmake[1]: *** [check] Error 139
gmake[1]: Leaving directory `/home/zmyrgel/tmp/chicken-4.7.0.6'
gmake: *** [check] Error 2
$

[zbigniew]

Believe it or not, I just got a symbolGC segfault on OS X / clang, with 4.8.0rc3. First time I ever got it. Ran make check again and it didn't happen.

[zbigniew]

It only happens one or twice every thousand tries. I ran it repeatedly 1000 times. Results are extremely inconsistent, except for how often it occurs on average:

for i in $(seq 1 1000); do ./symbolgc-tests -:w; done > /dev/null

Results of nine runs of 1,000 invocations each:

• 1 segfault
• 1 non-procedure call
• 1 non-procedure call
• no errors
• 2 non-procedure calls
• 2 non-procedure calls
• 1 non-procedure call, 2 segfaults
• 2 non-procedure calls, 2 segfaults
• 2 segfaults

Non-procedure call looks as expected:

Error: call of non-procedure: -2882303761508213667

        Call history:

        display   
        display   
        get-output-string         
        symbolgc-tests.scm:17: string->symbol     
        open-output-string        
        display   
        display   
        display   
        get-output-string         
        symbolgc-tests.scm:17: string->symbol     
        open-output-string        
        display   
        display   
        display   
        get-output-string         
        symbolgc-tests.scm:17: string->symbol           <--

[sjamaan]

Possibly related to the use of (an older version of?) Clang instead of GCC. Combined with the fact it only happens occasionally, this might explain why you never got this before.

[zbigniew]

Maybe, although I'm using clang 4.0, and I've been building with (earlier
versions) of clang (3.0, 3.1) for a while.

This could still be a bug in the runtime which depends on compiler or platform.

$ clang -v
Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)

[zbigniew]

Issue does not appear to be clang or LLVM. I get the same behavior with plain gcc-4.2 on 4.7.0.6 and 4.7.0.

gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

[felix]

Peter had this test endlessly repeating the other day. So there seems to be something wrong with the symbol GC in general.

[ckeen]

This has been fixed with d8c325760b080895a03aefb45d675e6722a768a3