On Fri, 10 Jun 2005, John Morrison wrote:
> Short version: I get a memory fault after loading shared object
> libraries, loading callback-sbcl.lisp, and a REALLY BIG compiled file
> of sb-alien bindings. Any advice? I am running 0.9.0.18 (from an
> RPM), and I have a recently-released RPM of 0.9.1-1.
While building from source might help, I doubt it. LDB most certainly
won't help, as you seem to be still in a live SBCL after the memory fault
-- LDB is strictly for post mortem.
My first guess is that you're simply running out of static space.
As a quick workaround: don't purify, and if you need to save an image,
do it with :PURIFY NIL.
If you're purifying because you need stuff that doesn't move, then
SB-INT:MAKE-STATIC-VECTOR may be what you need: it allocates vectors of
immediate objects directly to static space. Do not be overly alarmed by
the SB-INT in this case: once the dust settles I think it (or something
very much like it) is destined to move to SB-EXT. You get to beta-test it.
If you're feeling adventurous, then twiddling the static-space-* values in
src/compiler/target/parms.lisp may help by giving you a larger static
space; searching sbcl-devel archives should yield some advice for that.
Similarly, building SBCL with the first PURIFY in make-target-2.sh
commented out should also conserve _some_ static space, and may be
sufficient for your needs, but I rather doubt it.
As a longer term solution we should probably detect the end of static
space and signal a STORAGE-CONDITION if we run out of it.
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."