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

I have made some changes to the register pinning process. And it seems
to have fixed a --gc-stress crash on riscv (and on loongarch).
But the riscv machine I have access to is so slow I can't really make
--gc-stress tell anything.
Maybe someone who has a fast riscv machine can try --gc-stress.

On Sat, Feb 14, 2026 at 1:44 AM Charles Zhang <[email protected]> wrote:
>
> 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