Steel Bank Common Lisp

Xof pointed out that this might simply be heap exhaustion.  Here's the
complete output of the error message:

Argh! gc_find_freeish_pages failed (restart_page), nbytes=1864.
   Gen Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs Mem-age
   0:     0     0     0     0     0        0     0  2000000    0   0  0.0000
   1:     0     0     0     0     0        0     0  2000000    0   0  0.0000
   2:     0     0     0     0     0        0     0  2000000    0   0  0.0000
   3:    24 24975     0     0     0 102241008 154896 63288488    0   1  1.3994
   4:   130 103729   885  1329  1030 434238472 236536 251959464  430   1  1.3981
   5:     0     0     0     0     0        0     0  2000000    0   0  0.0000
   6:     0     0     0     0     0        0     0        0    0   0  0.0000
   Total bytes allocated=536479480
fatal error encountered in SBCL pid 22430

-- 
When it comes to electronic voting, most liberals are just plain
old-fashioned nuts.
        -- Joe Andrew, former chairman of the Democratic National Committee

Eric Hanchrow <offby1@...> writes:

> This is 0.8.19, that I built myself with 
>
>     (enable :sb-show-assem)
>     (enable :sb-show)
>     (enable :sb-ldb)

This is indeed an odd set of features to compile with.  (I wouldn't
recommend :sb-show* to anyone who isn't debugging SBCL itself: they're
almost completely useless in all other situations, to the best of my
knowledge.)

> I've got the SBCL process sitting in its LDB debugger, and will keep
> it there for a while, if that's of any use.  I don't know the first
> thing about LDB, so I haven't typed anything other than "help" and
> "backtrace".

So I'm pretty sure that this is an unfortunate poor behaviour on
sbcl's part, but only given that you've exhausted the available heap.
(See <http://paste.lisp.org/display/5894> for some evidence.)

If you have ~ 1 million keys in your hash table of strings with
approximately 200 characters, that would be (since the hash table
needs to store keys, and since a string in SBCL 0.8.19 is encoded in
UCS-2) about 800Mb, which is comfortably above SBCL's heap limit on
x86.

So the real bug here is SBCL's lack of graceful heap exhaustion
(throwing a storage-condition or somesuch); it would be very nice to
recover gracefully from these attempts to cons over the limit...

Cheers,

Christophe