Re: STORAGE-CONDITION: Binding stack
Robert Goldman <[email protected]> Thu, 26 Mar 2026 09:24:05 -0500
| Newsgroups | gmane.lisp.steel-bank.general |
|---|---|
| Message-ID | <[email protected]> |
--===============3239843582494472941==
Content-Type: multipart/alternative;
boundary="=_MailMate_24AEC3FA-FBDD-48D4-8961-E0A0EFB85733_="
--=_MailMate_24AEC3FA-FBDD-48D4-8961-E0A0EFB85733_=
Content-Type: text/plain; format=flowed; markup=markdown
Are you sure about that? I can find `--control-stack-size` in
`sbcl/src/runtime/runtime.c` but I don't see `--binding-stack-size` in
there.
Also, I did try recompiling with the binding stack size expanded by a
factor of 10 and I got the same error.
I might be able to change the source code, but ... why is this so much
worse on SBCL than other lisps? It's obviously not just that it's
conservative about the (default) stack size -- it's something about the
way dynamic binding is handled.
Or, more accurately, since I'm not an expert on SBCL internals: it
*appears* that it's something about the way dynamic binding is handled.
> Looks like a recursive function with a let or let*
>
> SBCL is much more conservative regarding the stack size than
> commercial Lisps.
>
> You can increase the stack size
>
> sbcl --dynamic-space-size 4096 --control-stack-size 8
> --binding-stack-size 4 # or higher values
>
> But the best would be to correct the code, avoid binding in recursive
> function (pass the value as an optional argument, for example).
>
> On 26-03-2026 2:16 AM, Robert Goldman wrote:
>
>> I have a large test script which has been failing for me with this
>> error:
>>
>> STORAGE-CONDITION: aborted for safety.
>> #<SB-KERNEL::BINDING-STACK-EXHAUSTED {7005C046B3}>
>>
>> What's the appropriate method for addressing this problem?
>> --control-stack-size and --dynamic-space-size do not appear to affect
>> this (I haven't been exhaustive in testing). Reading some old
>> traffic, it seems like the binding stack size can only be set when
>> SBCL is built. Is that correct?
>>
>> Weirdly, this same code runs fine on both Clozure and Allegro Common
>> Lisp, and I usually think of SBCL as being the most optimized of the
>> available implementations. But I gather there's something quite
>> different about the way SBCL handles specials.
>>
>> I guess I think the right answer is to rebuild SBCL for this purpose,
>> but wanted to ask, in case I am wrong.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Sbcl-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
>
> ------------------------------
>
> End of Sbcl-help Digest, Vol 229, Issue 2
> *****************************************
--=_MailMate_24AEC3FA-FBDD-48D4-8961-E0A0EFB85733_=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body><div style=3D"font-family: sans-serif;"><div class=3D"markdown" sty=
le=3D"white-space: normal;">
<p dir=3D"auto">Are you sure about that? I can find <code style=3D"margi=
n: 0 0; padding: 0 0.25em; border-radius: 3px; background-color: #F7F7F7;=
">--control-stack-size</code> in <code style=3D"margin: 0 0; padding: 0 0=
=2E25em; border-radius: 3px; background-color: #F7F7F7;">sbcl/src/runtime=
/runtime.c</code> but I don't see <code style=3D"margin: 0 0; padding: 0 =
0.25em; border-radius: 3px; background-color: #F7F7F7;">--binding-stack-s=
ize</code> in there.</p>
<p dir=3D"auto">Also, I did try recompiling with the binding stack size e=
xpanded by a factor of 10 and I got the same error.</p>
<p dir=3D"auto">I might be able to change the source code, but ... why is=
this so much worse on SBCL than other lisps? It's obviously not just th=
at it's conservative about the (default) stack size -- it's something abo=
ut the way dynamic binding is handled.</p>
<p dir=3D"auto">Or, more accurately, since I'm not an expert on SBCL inte=
rnals: it <em>appears</em> that it's something about the way dynamic bind=
ing is handled.</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
solid #777777; color: #777777;">
<p dir=3D"auto">Looks like a recursive function with a let or let*</p>
<p dir=3D"auto">SBCL is much more conservative regarding the stack size t=
han commercial Lisps.</p>
<p dir=3D"auto">You can increase the stack size</p>
<p dir=3D"auto">sbcl --dynamic-space-size 4096 --control-stack-size 8 --b=
inding-stack-size 4 # or higher values</p>
<p dir=3D"auto">But the best would be to correct the code, avoid binding =
in recursive function (pass the value as an optional argument, for exampl=
e).</p>
<p dir=3D"auto">On 26-03-2026 2:16 AM, Robert Goldman wrote:</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
solid #777777; border-left-color: #999999; color: #999999;">
<p dir=3D"auto">I have a large test script which has been failing for me =
with this error:</p>
<p dir=3D"auto">STORAGE-CONDITION: aborted for safety. #<SB-KERNEL::BI=
NDING-STACK-EXHAUSTED {7005C046B3}></p>
<p dir=3D"auto">What's the appropriate method for addressing this problem=
? --control-stack-size and --dynamic-space-size do not appear to affect t=
his (I haven't been exhaustive in testing). Reading some old traffic, it =
seems like the binding stack size can only be set when SBCL is built. Is =
that correct?</p>
<p dir=3D"auto">Weirdly, this same code runs fine on both Clozure and All=
egro Common Lisp, and I usually think of SBCL as being the most optimized=
of the available implementations. But I gather there's something quite d=
ifferent about the way SBCL handles specials.</p>
<p dir=3D"auto">I guess I think the right answer is to rebuild SBCL for t=
his purpose, but wanted to ask, in case I am wrong.</p>
</blockquote>
<p dir=3D"auto">-------------- next part --------------<br>
An HTML attachment was scrubbed...</p>
<hr style=3D"border: 0; height: 1px; background: #333; background-image: =
linear-gradient(to right, #ccc, #333, #ccc);">
<hr style=3D"border: 0; height: 1px; background: #333; background-image: =
linear-gradient(to right, #ccc, #333, #ccc);">
<p dir=3D"auto">Subject: Digest Footer</p>
<hr style=3D"border: 0; height: 1px; background: #333; background-image: =
linear-gradient(to right, #ccc, #333, #ccc);">
<p dir=3D"auto">Sbcl-help mailing list<br>
<a href=3D"mailto:[email protected]" style=3D"color: #77777=
7;">[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/sbcl-help" style=3D=
"color: #777777;">https://lists.sourceforge.net/lists/listinfo/sbcl-help<=
/a></p>
<hr style=3D"border: 0; height: 1px; background: #333; background-image: =
linear-gradient(to right, #ccc, #333, #ccc);">
<p dir=3D"auto">End of Sbcl-help Digest, Vol 229, Issue 2</p>
<hr style=3D"border: 0; height: 1px; background: #333; background-image: =
linear-gradient(to right, #ccc, #333, #ccc);">
</blockquote>
</div>
</div>
</body>
</html>
--=_MailMate_24AEC3FA-FBDD-48D4-8961-E0A0EFB85733_=--
--===============3239843582494472941==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============3239843582494472941==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help
--===============3239843582494472941==--