Hello all,
I'm using CMU CL 17f on an Ultra with Caspar Dik's cmucl-workaround.c
fix. It works well most of the time, but if I do something heavy then
I eventually get the following:
GC lossage. No scavenge function for object 0xefffe5a6
LDB monitor
ldb>
I have no idea what this means or how to avoid it. Would it help for
me to recompile the binary or to get a binary compiled for Ultra? I
don't even know if this problem is Ultra specific since the only
machine I'm using is an Ultra.
Any help would be appreciated.
I just restructured my application to use CLOS (PCL), which seems to
cause it to run an order of magnitude slower and this problem pops up
much more often :( :(
Johan Parin
Ericsson AXE Research & Development, Stockholm, SWEDEN
Johan Parin <······@uab.ericsson.se> writes:
>Hello all,
>I'm using CMU CL 17f on an Ultra with Caspar Dik's cmucl-workaround.c
>fix. It works well most of the time, but if I do something heavy then
>I eventually get the following:
>GC lossage. No scavenge function for object 0xefffe5a6
>LDB monitor
>ldb>
It means that the GC found an object in memory no scavenge function is
know for. Normally, each kind of CMUCL object has a scavenge
function that is found by looking at the object's type tag or header.
In theory, only the basic object types of the CMUCL runtime can show
up in memory. I think it is very unlikly you created a kind of object
the GC doesn't know about, instead I think you clobbered your memory
and the meory area in question is filled with junk.
Obviously, you could do so from an Alien function or by array access
with compiler settings that disabled array bound checks.
Try with conservative compiler settings, a different Lisp system or
maybe uncompiled code to see whether it runs on a range error.
It is possible that you didn't globber your memory and that in fact
the GC somehow has a bug and fails to precess a legal object. In that
case, you could try a x86 CMUCL version (FreeBSD or Linux), they have
a complete different GC.
It is also possible to compile a Sparc/Solaris version with the
conservative GC (nontrivial). You could also turn GC off, of course,
but I think these would only hide a bug (in your code or CMUCL's
Solaris version) that may come out as wrong data someplace.
>I have no idea what this means or how to avoid it. Would it help for
>me to recompile the binary or to get a binary compiled for Ultra? I
>don't even know if this problem is Ultra specific since the only
>machine I'm using is an Ultra.
The Solaris and Alpha ports in general seem not as robust as SunOS or
the new x86 ports, gessing from the number of bug report for GC
lossages, invalid memory references and such.
Solaris 2.5 had a bug where the address of a page fault isn't reported
corrctly. Normally, that should do any harm, but maybe you triggered
some unusual condition. The ID for the fix is 103093-06.
>Any help would be appreciated.
>I just restructured my application to use CLOS (PCL), which seems to
>cause it to run an order of magnitude slower and this problem pops up
>much more often :( :(
CLOS/PCL is not where CMUCL shines, maybe Common Lisp doesn't either.
Do you know if the methods to prefeed the CLOS method cache? Some
people said they had good success with it, although I didn't use it
myself.
Hope this helps. If you can contribute a test case - no matter how
much code - that triggers this bug repeatable, please contribute it to
·········@cons.org (if it is big, please store it elsewhere and send
the Url).
Hope this helps.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin