segfault in symbolGC tests on openbsd 5.0 with 4.7.0.3-stability

[Jim Ursetto]

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

[Christian Kellermann]

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->...... <--

[Jim Ursetto]

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

[Christian Kellermann]

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

[Christian Kellermann]

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
$

[Jim Ursetto]

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.

[Jim Ursetto]

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.

[Jim Ursetto]

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)

[Jim Ursetto]

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 winkelmann]

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

[Christian Kellermann]

This has been fixed with d8c325760b080895a03aefb45d675e6722a768a3