Re: [Sbcl-devel] Re: [Sbcl-help] Need advice in tracking down SBCL Memory fault

[Nikodemus S. <nik...@ra...>]

On Sat, 11 Jun 2005, John Morrison wrote:

>> 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.
>
> OK, I can do that ... thanks!  Two questions immediately spring to
> mind: (1) Is there any way I can verify that (that it's a simple space
> issue and not some Deep Dark Coding Malevolence)?

One simple but tedious way would be to add sufficient debugging output
to the signal handling in the runtime to see where the final memory fault 
comes from: it should coincide with the end of static space.

(The above could also be discerned with gdb given sufficient patience,
but I'd be more inclined to add output.)

Another option would be to mprotect the last page of static space
and detect that in the runtime, printing an appropriate flaming death 
message.

Yet another would be twiddling the spaces: if that helps, it was probably 
the cause...

> (2) Will/might
> there be fewer such problems with a 64-bit version of SBCL?

64-bitness has no direct bearing, but given the indecently large memory 
space I would suppose in effect that might be the case.

> The "callback" trampoline stuff has an advisory about that, but I
> cannot recall whether either the infrastructure or all my callbacks
> require the purify to keep them from moving...

If these are the callbacks I'm thinking about then purifying should not be 
necessary, but since I don't know which callbacks you are using...

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."