Re: SBCL 2.6.1 SIGILL during make-target-2 warm init on riscv64/linux/musl

I agree with Stas, it’s most likely a GC thing. Threaded builds were always a bit flaky because of that, and I was never sure after removing LRA whether on-stack code really does get pinned correctly or not.
Although this seems like a regression - I think I had the test suite at least flushing through at one point.


On Friday, February 13, 2026, 10:26 PM, Stas Boukarev <[email protected]> wrote:

I'm willing to wager that memory just moves away from under it.

E.g. I run ./run-tests.sh debug.* --gc-stress on riscv and get

Unhandled TYPE-ERROR in thread #<SB-THREAD:THREAD tid=69302 "main
thread" RUNNING
                                  {4F96AC73}>:
  The value
    0
  is not of type
    SB-C:TN
  when binding SB-C::Y

On Sat, Feb 14, 2026 at 12:19 AM Christophe Rhodes via Sbcl-devel
<[email protected]> wrote:
>
> SIGILL can mean a number of different things.  One thing it can mean is
> that we have managed to encode an illegal instruction for your hardware.
> If that's the case, you could probably at least verify that by attaching
> gdb to the process and disassembling the memory around the faulting
> instruction: does most of it look like plausible Lisp code and there's
> just one bogus instruction?  Then that's probably it.
>
> Another thing it can mean is that our assembler is mostly fine, but
> somehow the Lisp process has decided to jump into things that aren't
> meant to be machine code (header data, error encoding, that kind of
> thing).  That's probably quite painful to start debugging: where have we
> jumped from?  If this looks like it might be the case, I would probably
> start by checking to see if *any* riscv/sbcl builds on your hardware: if
> none does, then it's something more fundamental, but if there is an SBCL
> that builds, you could bisect to find the first version that doesn't,
> and stare suspciously at that change.  If no version of SBCL runs on
> your hardware, I'd perhaps try swapping out the C library, because I'm
> not very familiar with musl, to see if that makes a difference.
>
> A third thing it might mean is that your hardware requires more
> instruction cache flushing (I think the SBCL term is
> "sanctify-for-execution") than we are currently doing.  (Some hardware
> has separate and non-coherent data and instruction caches to memory, so
> writing data to memory that is intended later to be executed, as SBCL
> does, requires us to make sure that the instruction cache will pick up
> the new stuff).
>
> Best wishes,
>
> Christophe
>
> Will Sinatra <[email protected]> writes:
>
> > Building SBCL 2.6.1 from source on native riscv64 hardware using ECL
> > 24.5.10 as the cross-compilation host results in a SIGILL (signal 4)
> > crash during the make-target-2 warm init phase. The cross-compilation
> > (make-host-1) and genesis complete successfully, and the freshly built
> > SBCL boots and begins warm compilation, but crashes after compiling
> > src/code/room.lisp.
> >
> > Build progression
> >
> > make-host-1 (cross-compilation via ECL): Completes successfully.
> > make-host-2 / genesis: Completes successfully. Cold core is generated.
> > Genesis passes are consistent.
> > make-target-2(warm init): The freshly built SBCL boots from the cold
> > core and begins compiling. During warm init, three missing foreign
> > symbols are reported at startup:
> >
> > Missing required foreign symbol 'fun_end_breakpoint_trap'Missing
> > required foreign symbol 'fun_end_breakpoint_end'Missing required
> > foreign symbol 'fun_end_breakpoint_guts'
> >
> > Despite these warnings, cold init proceeds and warm compilation
> > begins. The build successfully compiles many files (including the
> > disassembler) but crashes immediately after compiling
> > src/code/room.lisp.
> >
> > Crash output
> >
> > ; compiling file "src/code/room.lisp" (written 26 JAN 2026 09:10:11 PM):
> >
> > ; wrote /builds/.../obj/from-self/src/code/room.fasl
> > ; compilation finished in 0:00:01.999
> > CORRUPTION WARNING in SBCL pid 2678 tid 2678:
> > Signal 4 received (PC: 0x518e6f14)
> > Exiting.
> > Error opening /dev/tty: No such device or address
> > ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> > Command exited with non-zero status 1
> >
> > Signal 4 is SIGILL. The crash PC (0x518e6f14) falls within the dynamic
> > space (base 0x4F000000), indicating the illegal instruction is in
> > compiled Lisp code rather than the C runtime.
> >
> > The full build log is attached, and any suggestions on how to proceed
> > are sincerely appreciated!
>
>
> _______________________________________________
> Sbcl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel


_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel