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
{{ message }}
Repository navigation
Squirrel: TIC() and BOOT() leak two stack frames per call #3005
callSquirrelTick (src/api/squirrel.c:1712) and callSquirrelBoot (src/api/squirrel.c:1763) push the root table and the looked-up function and never pop them: on the success path both return with [root, fn] still on the VM stack. The same two frames #2965 fixed in callSquirrelIntCallback, which is balanced on every path now (0db123da).
The rate is lower here, since TIC() runs once a frame where the int callbacks run per scanline, so the leak is quiet. It is still unbounded: a long-running cart grows the VM stack for as long as it runs.
The fix is the same two pops the callback helper already has, on both the success and the error return.
From the issue description, it looks like callSquirrelTick() and callSquirrelBoot() are leaving the Squirrel root table and function on the VM stack, which causes the stack to grow over repeated calls.
My plan is to inspect the stack handling in these two functions and align it with the already-fixed pattern used in callSquirrelIntCallback(), making sure the stack is properly balanced on both success and error paths.
I’ll work on reproducing the issue locally, implement the fix, and verify that the stack no longer grows unexpectedly. Please let me know if there’s anything specific you’d like me to keep in mind while working on it.
Activity
HarshDhru23 commentedon Oct 8, 2026
Hi! I’d like to work on this issue.
From the issue description, it looks like
callSquirrelTick()andcallSquirrelBoot()are leaving the Squirrel root table and function on the VM stack, which causes the stack to grow over repeated calls.My plan is to inspect the stack handling in these two functions and align it with the already-fixed pattern used in
callSquirrelIntCallback(), making sure the stack is properly balanced on both success and error paths.I’ll work on reproducing the issue locally, implement the fix, and verify that the stack no longer grows unexpectedly. Please let me know if there’s anything specific you’d like me to keep in mind while working on it.