I normally run SBCL from Emacs using SLIME.  I start SBCL with "--dynamic-space-size 1325", which is the maximum that will work on my machine.

I have a program that causes SBCL to crash (about halfway to completion), with this error in the LDB:

Heap exhausted during garbage collection: 0 bytes available, 4112 requested.
 Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs Mem-age
   0:     0     0     0     0     0     0     0     0     0        0     0 13893632    0   0  0.0000
   1:     0     0     0     0     0     0     0     0     0        0     0 13893632    0   0  0.0000
   2:     0     0     0     0     0     0     0     0     0        0     0 13893632    0   0  0.0000
   3:     0     0     0     0     0     0     0     0     0        0     0 13893632    0   0  0.0000
   4:     0     0     0     0     0     0     0     0     0        0     0 13893632    0   0  0.0000
   5: 201564 201566     0     0 78910 113819     9   482     0 615144744 176284376 425908664    0   7  0.6698
   6:     0     0     0     0  6063  1293     0     0     0 30130176     0  2000000 5845   0  0.0000
   Total bytes allocated    = 1086438152
   Dynamic-space-size bytes = 1389363200
GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = in progress
   *STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 5320(tid 4055944):
Heap exhausted, game over.


I'm not entirely sure how to interpret that, so any guidance on understanding the problem would be appreciated.

Here's where it gets puzzling. (At least to me.)  The top-level function of my program does this:

(defun doall ()
  (doit 2009)
  (doit 2010)
  (doit 2011)
  (doit 2012)
  (doit 2013)
  (doit 2014))


If instead of using this, I simply execute all the "doit"s sequentially from the REPL, they work fine and there's no crash.  Here's (room) at the end of executing sequentially:

Dynamic space usage is:   395,955,632 bytes.
Read-only space usage is:      3,160 bytes.
Static space usage is:         2,592 bytes.
Control stack usage is:        2,880 bytes.
Binding stack usage is:          568 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
  171,749,424 bytes for   151,673 simple-array-unsigned-byte-32 objects.
  94,833,048 bytes for   126,904 simple-vector objects.
  28,216,976 bytes for 1,763,561 double-float objects.
  25,514,224 bytes for 3,189,278 cons objects.
  23,767,592 bytes for 2,051,668 bignum objects.
  52,144,488 bytes for 1,323,575 other objects.
  396,225,752 bytes for 8,606,659 dynamic objects (space total.)


That doesn't seem like it should be close to causing memory crash (if in fact I have 1325Mb of memory).

Any suggestions or help would be appreciated!

-- Scott Turner