[cmucl-help] Re: Doing purification: gc invariant lost (purify.c:510)
Jared C. Davis wrote: > Hi, > > I think you're right that the problem seems to stem from > try-to-accept-all-commands not being tail-call optimized. > One other thing you could try. Since you basically call try-to-accept-all-commands forever until you get the command to save lisp, you can give up the recursive call. Just add an infinite loop around the body of try-to-accept-all-commands. (Leaving out the recursive call of course!) Let us know if this works. Ray
[cmucl-help] Re: Doing purification: gc invariant lost (purify.c:510)
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 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 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/
[cmucl-help] Re: Doing purification: gc invariant lost (purify.c:510)
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
[cmucl-help] Re: Doing purification: gc invariant lost (purify.c:510)
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 > > On examination of line 510, I see that there's a 1024-element array that is being used to hold valid heap pointers in the stack. We have exceeded the size of that array. So perhaps in your case your stack is so large that there are more than 1024 valid pointers. Can you run (room) before you run save-lisp and report the results here? It could be something as simple as increasing the size of the array. Although if your control stack is really large, some other approach may be needed since we probably don't want a multi-million element array that is large enough for the whole control stack. Ray
[cmucl-help] Re: Doing purification: gc invariant lost (purify.c:510)
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. > > In case this is the sort of thing that an expert wants to look at, I'd > be happy to provide instructions for how to reproduce the problem. > The program itself is quite small, but the error occurs after around > 20 minutes of computation from processing some 500 MB of input files, > so I will probably need to try to cut this down somewhat to give a > more useful example. > Yes, it would be helpful if you could simplify this somewhat. I'm not keen on getting 500 MB files to test with. Are you calling any foreign functions? I haven't had a GC invariant problem in a long time. Ray
