2.4.4 fails to build under Docker

[Andrew Kravchuk]

Hey, I'm trying to build SBCL in Docker using code from daewok/sbcl Docker image (basically just bootstrapping from binary SBCL 1.5.5 from Sourceforge). 2.4.3 builds just fine, 2.4.4 fails mid-build with the following error (full build log in attachment):

[305/306] src/code/target-format (0.315 sec)
[306/306] src/code/late-globaldb (0.043 sec)
                                                   47.746
; Math journal: wrote #P"obj/from-host/xfloat-math.lisp-expr" (6956 entries)
ctype cache metrics: Count LF Seek Hit maxPSL Mask
  VALUES : 46774 71.4% 8 FFFF
  List : 44012 67.2% 12 FFFF
  Set : 30306 46.2% 6 FFFF
  UNION : 23450 71.6% 8 7FFF
  EQL : 19294 NIL %
  NUMERIC : 10938 66.8% 7 3FFF
  FUN : 9516 58.1% 6 3FFF
  INTERSECTION : 7151 43.6% 5 3FFF
  MEMBER : 5462 66.7% 6 1FFF
  NEGATION : 3849 47.0% 9 1FFF
  Key-Info : 1545 37.7% 4 FFF
  ARRAY : 634 61.9% 5 3FF
  CONS : 467 45.6% 5 3FF
  Key-Info-Set : 453 44.2% 4 3FF
  CHARACTER-SET : 222 43.4% 4 1FF
  ALIEN-TYPE : 113 44.1% 3 FF
  UNKNOWN : 67 52.3% 4 7F
  CONSTANT : 59 46.1% 5 7F
  SIMD-PACK : 44 68.8% 8 3F
  SIMD-PACK-256 : 42 65.6% 8 3F
  HAIRY : 17 26.6% 3 3F
  MEMBER/EQ : 9 14.1% 2 3F
  FUN-DESIGNATOR : 5 7.8% 1 3F
  Total : 204429
Alien:
  FUN : 83 64.8% 5 7F
  POINTER : 17 26.6% 3 3F
  INTEGER : 8 12.5% 2 3F
  ARRAY : 4 6.3% 1 3F
  C-STRING : 3 4.7% 1 3F
  BOOLEAN : 1 1.6% 1 3F
  VALUES : 1 1.6% 1 3F
  ENUM : 0 0.0% 0 3F
  UNION : 0 0.0% 0 3F
  STRUCT : 0 0.0% 0 3F
  Total : 117
;
; compilation unit finished
; printed 1 note
Math journal: replaced from #P"obj/from-host/xfloat-math.lisp-expr"
[undoing binding stack and other enclosing state... mmap: wanted 82903040 bytes at 0x1000000000, actually mapped at 0x7d4738600000
fatal error encountered in SBCL pid 657(tid 0x7d473dcc7b80):
remap_free_pages: page moved, 0x1000000000 ==> (nil)

Error opening /dev/tty: No such device or address
done]
Welcome to LDB, a low-level debugger for the Lisp runtime environment.

2.4.4 also builds just fine w/out Docker, in real environment.

ulimit -a output under Docker is identical to the one in real environment:

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) 0
memory(kbytes) unlimited
locked memory(kbytes) 8192
process unlimited
nofiles 1048576
vmemory(kbytes) unlimited
locks unlimited
rtprio 0

Please advise which system knob I should tweak so that the build works.

[Douglas Katzman (dougk)]

I think Stas has already identified that this problem is that the old SBCL uses munmap/mremap to release memory after GC where newer SBCL uses madvise(DONTNEED). So 1.5.5 simply can not be used to bootstrap, and I can not think of any workaround, as the problem seems to be in the host lisp, and the OS being antagonistic to it.

[Andrew Kravchuk (awkravchuk)]

I've just got identical problem (now featuring dump of /proc/self/maps) trying to build latest master with SBCL 2.0.1. How exactly old are we talking here?
Also please note 1.5.5 version is able to build 2.4.3 under Docker flawlessly, so I suspect there's some kind of problem in 2.4.4 (and still in latest master); perhaps something related to new GC?

[Douglas Katzman (dougk)]

the necessary change is
commit 0ed28dbbd93582ed2efaaee28775227f3f411bbe
Author: Douglas Katzman <email address hidden>
Date: Fri Jun 17 16:12:53 2022 -0400

    linux: Never release a reserved memory range

    Give back memory to the OS without ever calling unmap.
    This logic remains fragile for all the other POSIXish OSes we support.

which is in this release

commit 4b8ada202db5c0066bc9e14c80bb7e4635c4c7e4
Author: Christophe Rhodes <email address hidden>
Date: Thu Jun 30 08:26:54 2022 +0100

    2.2.6: will be tagged as "sbcl-2.2.6"

[Andrew Kravchuk (awkravchuk)]

Building with 2.2.6 succeeded, thank you Douglas!

[Dale Gulledge (dgulledge)]

I can confirm that it was definitely the bootstrap LISP that was the problem. I saw this problem using 2.1.11 to build 2.4.5. Since I also have clisp installed, I used that to bootstrap. The build finished fine. Then to confirm I used the newly build SBCL 2.4.5 to rebuild itself. It worked.