Memory corruption in SBCL 1.3.18 and GCC 7

[Syll]

While trying to connect to some url with drakma, I get an error from SBCL 1.3.18. The problem does not appear in SBCL 1.3.17 (I checked by reinstalling it). I use the current (2017-06-11) version of quicklisp and drakma.

Run the following code (you need quicklisp) :

(ql) ; This function initializes quicklisp here, you should adapt/delete it
(ql:quickload :drakma)
(drakma:http-request "http://blog.developpez.com/xmlsrv/atom.php?blog=51")

Here is the result with backtrace :

"
CORRUPTION WARNING in SBCL pid 4543(tid 0x7ffff7fb5fc0):
Memory fault at (nil) (pc=0x40fb62, sp=0x7ffff6c6e8f8)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.

debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread
#<THREAD "main thread" RUNNING {1001F0E5F3}>:
  Unhandled memory fault at #x0.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-SYS:MEMORY-FAULT-ERROR)

0] ba

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1001F0E5F3}>
0: (SB-SYS:MEMORY-FAULT-ERROR)
1: ("foreign function: call_into_lisp")
2: ("foreign function: post_signal_tramp")
3: ("foreign function: funcall3")
4: ("foreign function: callback_wrapper_trampoline")
5: ("foreign function: #x20100D41")
"

The function does not fail on every URL. This one designate a feed that has been moved. I have the problem with a few other ones.

The error does not appear with SBCL 1.3.17.

$ sbcl --version
SBCL 1.3.18

$ uname -a
Linux yggdrasil 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux

* *features*

(:64-BIT :64-BIT-REGISTERS :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
 :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPACT-INSTANCE-HEADER
 :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS
 :FP-AND-PC-STANDARD-SAVE :GENCGC :IEEE-FLOATING-POINT :IMMOBILE-CODE
 :IMMOBILE-SPACE :INLINE-CONSTANTS :INTEGER-EQL-VOP :LARGEFILE :LINKAGE-TABLE
 :LINUX :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
 :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC
 :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR
 :RAW-INSTANCE-INIT-VOPS :RAW-SIGNED-WORD :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL
 :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS
 :SB-THREAD :SB-TRACEROOT :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES
 :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS
 :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS
 :UNBIND-N-VOP :UNDEFINED-FUN-RESTARTS :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP
 :X86-64)

[Stas Boukarev (stassats)]

Not reproducible.

[Syll (syll)]

I have recreated it on another Archlinux with SBCL 1.3.18 (fresh update of SBCL + fresh quicklisp + drakma installation) : same function call and same result.

Don't you get the error or is it "not reproducible" due to my quicklisp initialization ? In the first case, I can send you other URLs with the same error.

I don't know what to do with the stack trace I get : is there a mean to get more useful information when I am in the debugger ?

[okflo (okflo)]

same problem, BUT your testsite redirects to a https-connection, the error is caused by cl+ssl:

This is SBCL 1.3.18, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (ql:quickload :drakma)
To load "drakma":
  Load 1 ASDF system:
    drakma
; Loading "drakma"
.....
(:DRAKMA)
* (drakma:http-request "https://blog.developpez.com/xmlsrv/atom.php?blog=51")
CORRUPTION WARNING in SBCL pid 2702(tid 0x7ffff7fa7fc0):
Memory fault at (nil) (pc=0x40fb62, sp=0x7ffff6cb68c8)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.

debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread
#<THREAD "main thread" RUNNING {1001F0E613}>:
  Unhandled memory fault at #x0.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-SYS:MEMORY-FAULT-ERROR)
0] :backtrace

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1001F0E613}>
0: (SB-SYS:MEMORY-FAULT-ERROR)
1: ("foreign function: call_into_lisp")
2: ("foreign function: post_signal_tramp")
3: ("foreign function: funcall3")
4: ("foreign function: callback_wrapper_trampoline")
5: ("foreign function: #x20100D41")
6: ("foreign function: #x10020B7FBF")
7: (CL+SSL::INITIALIZE :METHOD CL+SSL::SSL-V23-METHOD :RAND-SEED NIL)
8: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN CL+SSL:ENSURE-INITIALIZED))
9: ((FLET #:WITHOUT-INTERRUPTS-BODY-386 :IN SB-THREAD::CALL-WITH-RECURSIVE-LOCK))
10: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK :IN CL+SSL:ENSURE-INITIALIZED) {7FFFF6CB6CBB}> #<SB-THREAD:MUTEX "SSL initialization" owner: #<SB-THREAD:THREAD "main thread" RUNNING {1001F0E613}>> T NIL)
11: (CL+SSL:ENSURE-INITIALIZED :METHOD #<unavailable argument> :RAND-SEED #<unavailable argument>)
12: (CL+SSL:MAKE-SSL-CLIENT-STREAM 5 :CERTIFICATE NIL :KEY NIL :PASSWORD NIL :METHOD #<unavailable argument> :EXTERNAL-FORMAT NIL :CLOSE-CALLBACK #<CLOSURE (LAMBDA NIL :IN DRAKMA::MAKE-SSL-STREAM) {100409BB7B}> :UNWRAP-STREAM-P T :CIPHER-LIST #<unavailable argument> :HOSTNAME "blog.developpez.com")
13: (DRAKMA::MAKE-SSL-STREAM #<SB-SYS:FD-STREAM for "socket 10.0.0.4:52344, peer: 87.98.128.58:443" {1003F3D533}> :CERTIFICATE NIL :KEY NIL :CERTIFICATE-PASSWORD NIL :VERIFY NIL :MAX-DEPTH #<unused argument> :CA-FILE NIL :CA-DIRECTORY NIL :HOSTNAME "blog.developpez.com")
14: (DRAKMA:HTTP-REQUEST #<PURI:URI https://blog.developpez.com/xmlsrv/atom.php?blog=51>)
15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (DRAKMA:HTTP-REQUEST "https://blog.developpez.com/xmlsrv/atom.php?blog=51") #<NULL-LEXENV>)
16: (EVAL (DRAKMA:HTTP-REQUEST "https://blog.developpez.com/xmlsrv/atom.php?blog=51"))
17: (INTERACTIVE-EVAL (DRAKMA:HTTP-REQUEST "https://blog.developpez.com/xmlsrv/atom.php?blog=51") :EVAL NIL)
18: (SB-IMPL::REPL-FUN NIL)
19: ((LAMBDA NIL :IN SB-IMPL::TOPLEVEL-REPL))
20: (S...

[Syll (syll)]

Thank you okflo. I don't know why I dont't get the whole backtrace here...

I just posted a bug on cl+ssl tracker : https://github.com/cl-plus-ssl/cl-plus-ssl/issues/48

I only get the error with SBCL 1.3.18 and the backtrace I get is not really useful. Mayby okflo could send more precise information to cl+ssl ? They have modified code on master about this part of cl+ssl but I get the "same" (?) error with this version.

[Syll (syll)]

SBCL 1.3.18 changelog contains :
"minor incompatible change: existing values of CFLAGS, ASFLAGS, CPPFLAGS, and LINKFLAGS will be incorporated into C compiler invocations when building from source. "

And the script used to build SBCL on Archlinux contains :
"
  export CFLAGS+=" -D_GNU_SOURCE -fno-omit-frame-pointer -DSBCL_HOME=/usr/lib/sbcl"
  export GNUMAKE="make"

  # build system uses LINKFLAGS and OS_LIBS to build LDFLAGS
  export LINKFLAGS="$LDFLAGS"
  unset LDFLAGS
  unset MAKEFLAGS
"

I don't know if it is important for the detection of the error by SBCL.

[okflo (okflo)]

addenum: this bug seems to only happen to sbcl 1.3.18 built on archlinux:

- I tried a fresh build of sbcl 1.3.18 on a Ubuntu 14.04.5 LTS: cl+ssl worked without a problem.
- I tried the binary (pre-built) version of 1.3.18 on archlinux: cl+ssl worked without a problem.
- Current ccl and cl+ssl on archlinux had NO problems.
- I built sbcl 1.3.18 on archlinux -> cl+ssl fails as described.

[Syll (syll)]

Thank you ofko.

I confirm that it does function with SBCL precompiled binaries.

Archlinux bug report here : https://bugs.archlinux.org/task/54565

[Stas Boukarev (stassats)]

It's actually caused by GCC 7, so you can close the archlinux ticket.

[Stas Boukarev (stassats)]

In 674ae94cefd465e593b7ae25d019a8f9db1ba73e