cannot compile sbcl-1.3.20 from source on linux x86

Bug #1710375 reported by Andrey Grozin on 2017-08-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

On linux amd64 everything's fine, but on x86 I get

+ echo //doing warm init - compilation phase
//doing warm init - compilation phase
+ echo '(load "loader.lisp") (load-sbcl-file "src/cold/warm.lisp")'
+ ./src/runtime/sbcl --core output/cold-sbcl.core --lose-on-corruption --no-sysinit --no-userinit
This is SBCL 1.3.20, an implementation of ANSI Common Lisp.
More information about SBCL is available at <>.

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.
COLD-INIT... ("Length(TLFs)= " 13578)
Memory fault at (nil) (pc=0x80634e2, sp=0xb79cdd08)
The integrity of this image is possibly compromised.
Welcome to LDB, a low-level debugger for the Lisp runtime environment.

What can I do to debug the situation?

The last version of sbcl which I can successfully compile on linux x86 is 1.3.1; starting from 1.3.18, I get this Memory fault at (nil).

Andrey Grozin (a-g-grozin) wrote :

Sorry, a typo. The correct version is:

The last version of sbcl which I can successfully compile on linux x86 is 1.3.17; starting from 1.3.18, I get this Memory fault at (nil).

Stas Boukarev (stassats) wrote :

Can't reproduce.

Changed in sbcl:
status: New → Incomplete
Andrey Grozin (a-g-grozin) wrote :

This is on a 32-bit Gentoo box. I've done git bisect and found that the commit which has introduced this Memory fault at (nil) problem is

grozin@elrond ~/sbcl $ git bisect bad
f4e758d44524b25ae23cafadb2f5eda76323f4dd is the first bad commit
commit f4e758d44524b25ae23cafadb2f5eda76323f4dd
Author: Douglas Katzman <email address hidden>
Date: Tue May 2 19:15:33 2017 -0400

    Give user more control over C compiler flags in src/runtime.

    And though clears EXTRA_CFLAGS, append them
    in contrib/ instead of assigning,
    to allow driving the contribs build step differently.

How can I find more useful information?

Douglas Katzman (dougk) wrote :

If the bisect is right, this should be simple to isolate as it's confined to the C make steps.
Try building prior to that change and save the C compiler/linker invocations from "make" in src/runtime into a file. Then build at that change, similarly saving the C compilation steps.
Try diffing them, or just eyeballing to see what looks suspicious.
In terms of trying to diagnose in 'ldb', you can type "backtrace", but as a first step it would be best to find out how the C code is being built differently.

Andrey Grozin (a-g-grozin) wrote :

The problem happened to be Gentoo-specific and is now solved, see
How can I close this bug?

Jan Moringen (scymtym) on 2017-10-13
Changed in sbcl:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers