Opened 5 years ago

Closed 4 years ago

#724 closed defect (fixed)

segfault in symbolGC tests on openbsd 5.0 with 4.7.0.3-stability

Reported by: zbigniew Owned by: felix
Priority: major Milestone: 4.9.0
Component: core libraries Version: 4.7.x
Keywords: Cc:
Estimated difficulty:

Description

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

Change History (14)

comment:1 Changed 5 years ago by 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->...... <--

comment:2 Changed 5 years ago by 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

comment:3 follow-up: Changed 5 years ago by 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

comment:4 in reply to: ↑ 3 Changed 5 years ago by 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

comment:5 Changed 5 years ago by sjamaan

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:6 Changed 5 years ago by zmyrgel

  • Resolution fixed deleted
  • Status changed from closed to reopened

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
$

comment:7 Changed 5 years ago by iraikov

  • Milestone set to 4.9.0

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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           <--

comment:10 Changed 5 years ago by 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.

comment:11 Changed 5 years ago by 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)

comment:12 Changed 5 years ago by 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)

comment:13 Changed 4 years ago by felix

  • Owner set to felix
  • Status changed from reopened to assigned

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

comment:14 Changed 4 years ago by ckeen

  • Resolution set to fixed
  • Status changed from assigned to closed

This has been fixed with d8c325760b080895a03aefb45d675e6722a768a3

Note: See TracTickets for help on using tickets.