[cmucl-help] Doing purification: gc invariant lost (purify.c:510)

[Jared C. Davis]

Hi,

I think you're right that the problem seems to stem from
try-to-accept-all-commands not being tail-call optimized.

I started glancing through the CMUCL manual (which is very nice, btw)
and it seems like the problem might be that *package* is being bound
outside the tail call.  When I move the recursive call outside of the
let, I get a noticeably different disassemble output, and the program
seems to be working.  At any rate, I will try with my whole data set,
but I think this seems like a good fix. :)

Thanks for all your help on this, Alex and Ray!

Jared

On Wed, Oct 28, 2009 at 9:48 PM, Raymond Toy <toy.raymond at gmail.com> wrote:
> Jared C. Davis wrote:
>> Hi,
>>
>> I have been hitting the following error in CMUCL 19f (and I think 20a)
>> when my program calls extensions::save-lisp:
>>
>>     [Doing purification: GC invariant lost!  File
>> "../../src/lisp/purify.c", line 510
>>
>> And I am then sent to LDB.  I seem to run into this same problem on
>> 32- and 64-bit Linux, and on Darwin. I'm a fairly novice user of
>> CMUCL, and am not sure how to proceed w.r.t. debugging this.
>>
> Ok.  I tried out the test.  Room shows that the stack is 58K bytes.
> Curiously, there are 1800 recursive calls to
> try-to-accept-all-commands.  I don't know why the compiler did tail-call
> that.   Perhaps because of the defun-comp macro to compile it function,
> instead of file-compiling the whole file.
>
> Anyway, if I increase that array size from 1024 to 10*1024, cmucl can
> save lisp.
>
> I didn't try it, but it would be interesting to see if file-compiling
> milawa.lisp would allow tail-calling try-to-accept-all-commands.  That
> would probably take care of the purify problem.
>
> Ray
>
>



-- 
Jared C. Davis <jared at cs.utexas.edu>
11410 Windermere Meadows
Austin, TX 78759
http://www.cs.utexas.edu/users/jared/