cannot compile sbcl-1.3.20 from source on linux x86

[Andrey Grozin]

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

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

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

Can't reproduce.

[Andrey Grozin (a-g-grozin)]

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 make-target-contrib.sh clears EXTRA_CFLAGS, append them
    in contrib/asdf-module.mk instead of assigning,
    to allow driving the contribs build step differently.

How can I find more useful information?

[Douglas Katzman (dougk)]

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

The problem happened to be Gentoo-specific and is now solved, see https://bugs.gentoo.org/632670
How can I close this bug?