Daniel Barlow <dan@...> writes:
> > I've been porting sbcl 0.7.9 to NetBSD with the generational GC (I
> > added the fault address passing functionality into the kernel and
> Cool! Any chance that your kernel patches will make it into NetBSD proper?
I can try send-pr'ing it, but I doubt it. Real SA_SIGINFO signals are in
the works and this way (additional argument to signal handlers) is a bit
hackish. It's not a large patch though, and should be applicable to both
1.5 and 1.6. I can also make available a GENERIC kernel with the change
applied (if I ever get the GC or whatever bug worked out).
> > This is SBCL 0.7.9, an implementation of ANSI Common Lisp.
> > [...]
> > fatal error encountered in SBCL runtime system:
> > no scavenge function for object 0x08054ed6 @ 0x550dc724 (widetag 0xcc)
> > There's no LDB in this build; exiting.
> First look at src/runtime/sbcl.h to find out what kind of object has
> that widetag. Then edit customize-target-features.lisp-expr to add
Unfortunately there is no widetag 0xcc defined in sbcl.h. The
sbcl-internals pages were helpful, I'll try the gdb investigations
suggested there later, and also compile with :sb-ldb later today.
The value at that address is initially 0x08054ed0 when cold-sbcl.core
is brought in and changes to 0x08054ed6 shortly after that, hard to
say where though as I was just breakpointing on mmap().
My gdb lacks hardware watchpoints (ptrace(2) can't access the i386
debug registers), but I'm running it with a watchpoint at 0x550dc724
anyway to see if anything comes up within a few hours.
> How far does it get before it blows up in this way? Is this using the
> cold-sbcl.core or has it already got through the PCL build and dumped
> the real sbcl.core?
This happens soon after starting up with cold-sbcl.core.