Repository navigation
bound the AST height of flat script expressions - #1259
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.
The height limit of 1024 still let accepted scripts overflow the 1 MB default stack of an unoptimized Windows build when evaluated: each level of ExprBinaryArithmetic::evaluate() can take about 1 KB there, which is why ParserTest.LongFlatScriptIsRejected crashed in the windows-2022 Debug job. Use kMaxNestingDepth (256) for both limits, shorten the accepted 'wide' scripts to 200 terms and check that 300 terms are rejected. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks @aysha-afrah26. The height accounting is correct, and it sits in the one place every script goes through. The limit was too high, though. Evaluating (and destroying) a flat chain recurses once per operator, and in an unoptimized MSVC build each I pushed f7cc673 on top of a merge of master: the height limit is now |
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.