Repository navigation
bound the AST height of flat script expressions - #1259
Open
aysha-afrah26 wants to merge 1 commit into
Open
aysha-afrah26 wants to merge 1 commit into
aysha-afrah26 wants to merge 1 commit into
Conversation
The nesting cap in ScriptParser::parseExpr counts parser recursion only. A flat chain such as 1+1+1+... is parsed by the loop without recursing, but it builds a left-deep AST that evaluate() and the node destructors walk recursively, one frame per operator, so a long Script attribute passes tree creation and overflows the stack on the first tick. Track the height of the expression being built and reject it past 1024 levels, so the evaluation depth no longer grows with the script length.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The nesting cap from #1174 limits how deep
ScriptParser::parseExprrecurses, but not how tall the resulting AST gets. A left-associative chain like1+1+1+...is consumed by thewhileloop inparseExprat depth 1, yet each operator wraps the previous result as itslhs, so the tree is as tall as the expression is long.ExprBinaryArithmetic::evaluate()then recurses once per level, and so does theshared_ptrdestructor chain when the AST is freed.So a long
Script,_skipIf,_whileor postcondition attribute passescreateTreeFromTextand then takes the process down on the first tick:How long the script has to be depends on the stack of the thread that ticks the tree. In a Release build on macOS I measured about 256 bytes per level:
std::thread): crashes at 2,000 terms, roughly 4 KB of scriptValidateScriptitself, while the AST is destroyedThe parser now tracks the height of the expression it builds and throws a regular parse error past 1024 levels. That limit is deliberately higher than
kMaxNestingDepth, so the 1,000-term flat expression thatDeeplyNestedScriptIsRejectedexpects to be valid still parses and evaluates (I also checked it under ASan+UBSan and on a 512 KB thread). Heights add up across parentheses, so((1+1+...)+1+...)can't sidestep the limit by splitting the chain.The change is private to
ScriptParserinscript_parser.cpp, so there is no API or ABI change. The only behavior change is that a single expression taller than 1024 levels is rejected when the tree is created, instead of crashing when it runs.ParserTest.LongFlatScriptIsRejectedcrashes with SIGSEGV on master and passes with the fix. The full ctest suite passes in Release and with ASan+UBSan; the one Release failure,LoggerTest.SqliteLogger_ExecSqlStatement, fails the same way on untouched master. pre-commit (clang-format, codespell) passes. clang-tidy did not run locally because clangd-21 isn't installed here.