Saving core is broken on windows

[il71]

SBCL 2.1.2, Windows x86-64. Linux is OK.

There are random fails during save-lisp-and-die.
It may have smth to do with:

changes in sbcl-2.1.2 relative to sbcl-2.1.1:
    ** retain fewer dead objects when saving cores with precise collectors.

$ cat save-lisp.lisp

(format t "Before save-lisp-and-die~%")
(finish-output)

(sb-ext:save-lisp-and-die
  "a.exe"
  :executable t
  :application-type :console
  #+sb-core-compression :compression #+sb-core-compression t
  :save-runtime-options t
  :toplevel (lambda ()
              (format t "Memory: ~a Gb~%" (ash (sb-ext:dynamic-space-size) -30))
              (finish-output)))

$ cat run.sh
#!/bin/sh

i=0
while true
do
        i=`expr $i + 1`
        echo "--- Iter $i ---"
        sbcl --dynamic-space-size 2Gb --no-userinit --load save-lisp.lisp
        ./a.exe
done

$ sh run.sh

[cut]

--- Iter 4 ---
Before save-lisp-and-die
fatal error encountered in SBCL pid 1076420740:
maximum interrupt nesting depth (8) exceeded

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>

Also something seems not consistent in sbcl.core, which also was the result of
save-lisp-and-die. If I add some trivial shared object load to save-lisp.lisp via cffi,
I get:

--- Iter 5 ---

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

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

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file "c:\\ws\\ql\\setup.lisp".
  2: [ABORT ] Abort loading file "c:\\ws\\ql\\setup.lisp".
  3: Retry EVAL of current toplevel form.
  4:

[il71 (il71)]

May be bug is not related to "cores" but to memory corruption in general.

[Douglas Katzman (dougk)]

The change you highlighted wouldn't pertain to win32.

Did it definitely start showing up at 2.1.2 and not earlier? The C runtime was touched quite a lot for adding darwin+arm64 support, so that might have something to do with it.
Any chance you can narrow it down with a git bisect?

[il71 (il71)]

Yes, it is since 2.1.2. 2.1.1 is OK.
I'll try to bisect a litle later.

[il71 (il71)]

It's something in OS+tools. I've built sbcl 2.1.1 when it was released and it's ok. Now I can't build *any* version (including 2.1.1) that would work. I tried two machines and updated Windows 10, msys2 to latest versions.

[il71 (il71)]

Actually, not necessarily a tools fault. I see different contribs modules fail to compile each time I run build. And I've seen this before. Host compiler does not matter. It looks like the process of producing image is somehow not deterministic on Windows and I was just lucky that sbcl-2.1.1 turned out to be stable.

[Stas Boukarev (stassats)]

You're the only one reporting it. So, it's something on your end.

[il71 (il71)]

Good to know. I tried every env settings I could think of -- no luck.
Maybe it has something to do with Windows 10 20H2 builds I inadvertently got into and now can't roll back since I removed restore points.

[il71 (il71)]

It's not related to Windows 10 preview builds and reproduces also on Windows 10 1909 build on different machine.

[Stas Boukarev (stassats)]

Are you building with sb-linkable-runtime?

[il71 (il71)]

No, just:

sh make.sh --prefix=d:/sbcl