BLOAT bug?

[REM at MIT-MC (Robert Elton Maas)]

I currently believe that I am experiencing the same bug in L (i.e. LISP)
that I experienced in LINREL in MACSYMA.  I am doing a lot of bignum
arithmetic, and LIST SPACE is filling up and not emptying even though I
return to the top level and repeat the same computation.  Storage gradually
gets more and more full as I repeat the same calculation several times.
My calculation doesn't grow any global data structures.  It creates some
during each time I repeat the calculation (the same ones each time) and
they should go away when I ^G out of the ;BKPT GC-OVERFLOW and restart.
But they don't seem to go away.  Turning on ^D from inside the BKPT and
doing an explicit (GC) shows LIST is 25% empty which is consistant with
getting the BKPT.  Doing a $P somehow reclaims all but 10% by the time
the next GC is done, even though a check of my EVALFRAMEs in the most
likely spot shows only a tiny amount of storage is being used by my
program (this check is NOT exhaustive; this isn't the prime reason for my
belief in bug in LISP).  Doing a ^G then a (GC) also seems to reclaim
all but 10%, but since the next repeat of the same calculation yields
quicker ;BKPT (thus indicating that there is less storage available at
the start of the calculation) I'm bewildered.  Is there any way to easily
diagnose such problems?  I'd like to call some function which will map
down (1) atoms (2) stacks (3) accumulators  and tell me the name or
machine address where any suspicious giant data structure is located,
or simply add up the total sizes of all objects and tell me how much
I'm really using in each category.  MAPATOMS works for atoms, but I
don't know the internal pointers to stacks nor which acs are in use for
s-expressions so can't write these diagnostics myself without help.
Not wanting to spend weeks reading source code at 300 baud, I'm asking
the wizards for suggestions...