You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The value (expt 2 16) is derived from the implementation's value for call-arguments-limit.
Interpreted or compiled? Repeatably?
The above form seems to fail in both interpreted and compiled versions, but only on the first invocation. Then repeated invocations seem to succeed. This makes little sense, so I wonder if I am not testing what I think I am. Could this somehow be the underlying JVM replacing JITd code running the implementation when it fails?
CALL-ARGUMENTS-LIMIT used to be 50
We set it high in #440 based on arguments from @alanruttenberg which apparently didn't consider this corner case (Verify!).
We can "fix" this bug be setting it something under (expt 2 16): by quick experimentation (expt 2 15) works fine on my machine. As such, the actual call-argument-limit is gonna depend heavily where it is running. We should probably set it to something conservative.
Investigation
What do other implementations do?
TODO
Not the stepper
This bug has been present since at least abcl-1.8.0.
This bug is a regression from abcl-1.9.1 in which the ABCL-STEPPER contrib enables interactive stepping through forms by instrumenting the CL:EVAL with machinery that should only impact performance when stepping is active. Apparently this is not the case, so we need to go back through the code to remove side-effects @alejandrozf.
From reviewing the stepper instrumentation, it could definitely be made more efficient when the stepper is not active by following the original codepath when Lisp.stepper is not true.
The text was updated successfully, but these errors were encountered:
easye
changed the title
EVAL of EQUALP across long lists blows up stack
MAX-ARGUMENT-LIMIT is too high
Dec 3, 2023
easye
changed the title
MAX-ARGUMENT-LIMIT is too high
CALL-ARGUMENT-LIMIT is too high
Dec 3, 2023
Background
Bug EVAL of EQUALP across long lists blows up stack
In triaging why the CALL-ARGUMENTS-LIMIT.4 test fails when invoked under SLIME but works from an unadorned top-level call.
I managed to reduce the failure to the following form which doesn't require one to be using SLIME to trigger it:
The value
(expt 2 16)
is derived from the implementation's value forcall-arguments-limit
.Interpreted or compiled? Repeatably?
The above form seems to fail in both interpreted and compiled versions, but only on the first invocation. Then repeated invocations seem to succeed. This makes little sense, so I wonder if I am not testing what I think I am. Could this somehow be the underlying JVM replacing JITd code running the implementation when it fails?
CALL-ARGUMENTS-LIMIT used to be 50
We set it high in #440 based on arguments from @alanruttenberg which apparently didn't consider this corner case (Verify!).
We can "fix" this bug be setting it something under
(expt 2 16)
: by quick experimentation(expt 2 15)
works fine on my machine. As such, the actualcall-argument-limit
is gonna depend heavily where it is running. We should probably set it to something conservative.Investigation
What do other implementations do?
TODO
Not the stepper
This bug has been present since at least abcl-1.8.0.
This bug is a regression from abcl-1.9.1 in which the ABCL-STEPPER contrib enables interactive stepping through forms by instrumenting theCL:EVAL
with machinery that should only impact performance when stepping is active. Apparently this is not the case, so we need to go back through the code to remove side-effects @alejandrozf.Instrumentation for ABCL-STEPPER added as 558a45b
From reviewing the stepper instrumentation, it could definitely be made more efficient when the stepper is not active by following the original codepath when
Lisp.stepper
is nottrue
.The text was updated successfully, but these errors were encountered: