solc: Stack overflow importing large AST from json file

[jaa2]

Description

Importing an AST with --import-ast using a large JSON file results in a stack overflow and segmentation fault with certain output options.

A quick run with memcheck shows that it stems from a regex match.

Environment

• Compiler version: 0.8.16-develop.2022.6.21+commit.c3ea8661.mod.Linux.g++
• Target EVM version (as per compiler settings): london
• Operating system: Linux

Steps to Reproduce

Create a large AST as JSON. Here is Uniswap V3 as an example (20.2 MB) from the external tests: uniswap_ast.zip

Try generating IR output - currently segfaults:

solc --import-ast ./164dbdb3af44e9eea766cd449cf8864c.json --ir

Try generating assembly from IR - currently segfaults:

solc --import-ast ./164dbdb3af44e9eea766cd449cf8864c.json --via-ir --asm

Regular assembly with the --asm flag only works as expected for this file.

[Marenz]

I believe this won't be too difficult to solve, so marking this as easy/good first issue, but in case I am wrong, feel free to comment/correct here

[matheusaaguiar]

I have tracked down the stack overflow to a regex_search call.
Apparently when the size of the string_view is sufficiently large (39547 in the example of this issue), the regex_search produces the stack overflow. It seems to be a known problem, since I have found some bug reports about similar situations with regex_search.
Not sure how it could be fixed. I guess we can't split the string_view being searched. I thought of merging two or more match_results returned from successive "range-restricted" regex searches (search first n positions, then next n or less until the end), but it is not possible.

[matheusaaguiar]

So far here is the situation: IR is generated with comments next to instructions indicating the source location.

 /// @src 19:243:377  ",\"src\":\"45:22:19\"},{\"abstract\":false,\"baseContracts\":[],\"canonicalName\":\"FixedPoint96\",\"contractDependencies\":[],\"contractKind\":\"libra"

The comments may contain some "garbage" which come from debug info (as reported in issue #12168). The debug info comes from method dispenseLocationComment.
Looking at method parseSrcComment, the "garbage" which comes after the source location is not used and does not seem to affect the return value. Maybe, we could just filter out the debug info which in some cases is large enough to cause segfault. I tested that approach and then there is a stack too deep exception:

Uncaught exception:
/solidity/libyul/backends/evm/EVMObjectCompiler.cpp(115): Throw in function void solidity::yul::EVMObjectCompiler::run(solidity::yul::Object&, bool)
Dynamic exception type: boost::wrapexcept<solidity::yul::StackTooDeepError>
std::exception::what: Variable ret_0 is 1 slot(s) too deep inside the stack.
[solidity::util::tag_comment*] = Variable ret_0 is 1 slot(s) too deep inside the stack.

I guess that is another problem with too long sequences of chars. I will continue to investigate from this point now, until we can decided the best solution.

[jaa2]

stack too deep exception

This is actually the expected output without --optimize

[matheusaaguiar]

Yes, just checked it and with --optimize there is no error.

[Marenz]

Probably related: #13496