From: Daniel B. <da...@te...> - 2002-11-09 03:06:57
|
Valtteri Vuorikoski <vu...@pu...> 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 > wrote some adapter functions to hopefully make BSD signals look > sufficiently like SIGINFO signals). I have attempted to generate a Cool! Any chance that your kernel patches will make it into NetBSD proper? > 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 sb-ldb (LAMBDA (LIST) (cons :sb-ldb list)) and rebuild. Next time you'll get dropped into the ldb> monitor where you can poke around a bit (or even, attach gdb to the process and poke around using that) ldb> print 0x08054ed6 might be one thing to try. http://ww.telent.net/sbcl-internals/gdb and http://ww.telent.net/sbcl-internals/ldb are both worth looking at if you haven't already. Unfortunately, GC lossage is in my experience rarely a GC problem and more often a problem elsewhere in the system that only gets picked up at GC time. If your platform has hardware watchpoints you may want to run under gdb and set a watch on writes to 0x550dc724, to see if anything looks suspicious. 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? -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |