Eric Schulte <schulte.eric@...> writes:
> Does anyone have any suggestions, either related to this sort of memory
> debugging in general, or specifically related to how to map dynamic
> memory to lisp objects?
(i know very little about sbcl's internals, this is what i did when i
hit a similar situation, take it with a (big) grain of salt)
i was in a very similar situation recently trying to track down which
(of way too many) caches was holding on to objects too long (and it
turned out it was holding on to 1000x more objects than i was
i ended up successfully using map-allocated-objects, but with two
1) i couldn't realiably allocate any memory from within the
map-allocated-objects callback. so i had to pre allocate any data i
needed and, if it turned out i needed more data than i thought, abort
the loop, pre-allocate more data, and try again.
2) any objects i discovered in the callback to map-allocated-objects
wouldn't be valid outside of the dynamic scope of that callback (so i
couldn't reliably just store the objects pointed to by my roots in a
vector or something, i ended up having to use a secondary id separte
from just #'eq (i had integer ids on all my objects already, so it
worked out pretty well in my case). i could though #'eq test any object
passed to the map-allocated-objects callback to any other object i had
outside of the map-allocated-objects call.
however, within the callback function i could do just about whatever i
wanted, typecase worked fine, walking over vectors and following
pointers also worked fine (though, obviously, figuring out the back
pointers required multiple calls to map-allocated-objects).
3) i had to wrap the map-allocated-objects in a without-gcing macro
(even though map-allocated-objects should already have that), no idea
what i was doing which made that important, but it worked for me.
and, of course, map-allocated-objects was recently rewritten, so,
depending on how new your sbcl is, this may not apply at all.