What are Clang-tidy command line parameters? Could you provide call stack trace?

What are Clang-tidy command line parameters? Could you provide call stack
trace?

This is what I used to call this function, and the resulting output:
[root@f7f611fd09c7 host_dir]# clang-tidy main.cpp
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "main.cpp"
No compilation database found in /host_dir or any parent directory
fixed-compilation-database: Error while opening fixed database: No such file or directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
Segmentation fault

Can't reproduce this:

root@fb0b075aa3ea:/build# cat >/tmp.q.cc
#include
int main()
{
const std::string xml_file_system =
std::string() + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + ""
+ "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "" + "";
}
root@fb0b075aa3ea:/build# clang-tidy /tmp.q.cc
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "/tmp.q.cc"
No compilation database found in / or any parent directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
root@fb0b075aa3ea:/build#

Apparently, details are needed: how you build clang-tidy, which checks you run, what docker container you use (is it crashing without docker, btw?), etc. Please also try with the current SVN HEAD build of clang-tidy.

BTW, what does ulimit -s tell? The crash may be a simple stack overflow, in which case you need to raise the relevant limit. On my machine it's 8MB and there's no crash.

Also, if there's no ulimit binary in your container, try cat /proc/self/limits:
root@f1c478aec83f:/build# cat /proc/self/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
...

Actually, I can reproduce this. At least, in one build configuration I can see what most likely is a stack overflow:
./bin/clang-tidy -checks=-,abseil-str-cat-append,abseil-upgrade-duration-conversions /tmp/q.cc --
#​0 0x0000000000659c74 PrintStackTraceSignalHandler(void) (./bin/clang-tidy+0x659c74)
#​1 0x0000000000658002 llvm::sys::RunSignalHandlers() (./bin/clang-tidy+0x658002)
#​2 0x000000000065a378 SignalHandler(int) (./bin/clang-tidy+0x65a378)
#​3 0x00007f0789509890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf890)
#​4 0x00000000017daf07 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively(clang::ast_type_traits::DynTypedNode const&, clang::ast_matchers::internal::DynTypedMatcher const&, clang::ast_matchers::internal::BoundNodesTreeBuilder*, clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode) (./bin/clang-tidy+0x17daf07)
#​5 0x00000000017dadf6 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively(clang::ast_type_traits::DynTypedNode const&, clang::ast_matchers::internal::DynTypedMatcher const&, clang::ast_matchers::internal::BoundNodesTreeBuilder*, clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode) (./bin/clang-tidy+0x17dadf6)
#​6 0x00000000017db7f9 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively(clang::ast_type_traits::DynTypedNode const&, clang::ast_matchers::internal::DynTypedMatcher const&, clang::ast_matchers::internal::BoundNodesTreeBuilder*, clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode) (./bin/clang-tidy+0x17db7f9)
#​7 0x00000000017dadf6 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively(clang::ast_type_traits::DynTypedNode const&, clang::ast_matchers::internal::DynTypedMatcher const&, clang::ast_matchers::internal::BoundNodesTreeBuilder*, clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode) (./bin/clang-tidy+0x17dadf6)
#​8 0x00000000017db7f9 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively(clang::ast_type_traits::DynTypedNode const&, clang::ast_matchers::internal::DynTypedMatcher const&, clang::ast_matchers::internal::BoundNodesTreeBuilder*, clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode) (./bin/clang-tidy+0x17db7f9)
(and so on)

Now the question is how practical is the code sample you posted? Is it representative of the depth of AST in some real code? Since clang uses recursion in multiple places, it's possible to create a code sample that will lead to a stack overflow for any given stack size.

However, we could improve the stack usage on particular recursive call paths, if the current state is problematic for real-world code.

This is a simplification of real word code generated by a third party tool we use. The tool generates XML specifications for the Genicam standard inline in header files. One string composed of thousands of lines all separated by "+".

This causes problems for us even thought we treat these generated files as a system headers. clang-tidy still need to parse them when analyzing our code.

We have worked around this by post-processing the files, removing all the "+"s. Still, I think this is a valid issue. I would expect clang-tidy to support whatever clang can compile.

Actually, I can reproduce this. At least, in one build configuration I can
see what most likely is a stack overflow:
./bin/clang-tidy
-checks=-,abseil-str-cat-append,abseil-upgrade-duration-conversions
/tmp/q.cc --
#​0 0x0000000000659c74 PrintStackTraceSignalHandler(void)
(./bin/clang-tidy+0x659c74)

#​1 0x0000000000658002 llvm::sys::RunSignalHandlers()
(./bin/clang-tidy+0x658002)

#​2 0x000000000065a378 SignalHandler(int) (./bin/clang-tidy+0x65a378)

#​3 0x00007f0789509890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0xf890)

#​4 0x00000000017daf07 clang::ast_matchers::internal::(anonymous
namespace)::MatchASTVisitor::matchesAncestorOfRecursively(clang::
ast_type_traits::DynTypedNode const&,
clang::ast_matchers::internal::DynTypedMatcher const&,
clang::ast_matchers::internal::BoundNodesTreeBuilder*,
clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode)
(./bin/clang-tidy+0x17daf07)
#​5 0x00000000017dadf6 clang::ast_matchers::internal::(anonymous
namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively(clang::
ast_type_traits::DynTypedNode const&,
clang::ast_matchers::internal::DynTypedMatcher const&,
clang::ast_matchers::internal::BoundNodesTreeBuilder*,
clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode)
(./bin/clang-tidy+0x17dadf6)
#​6 0x00000000017db7f9 clang::ast_matchers::internal::(anonymous
namespace)::MatchASTVisitor::matchesAncestorOfRecursively(clang::
ast_type_traits::DynTypedNode const&,
clang::ast_matchers::internal::DynTypedMatcher const&,
clang::ast_matchers::internal::BoundNodesTreeBuilder*,
clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode)
(./bin/clang-tidy+0x17db7f9)
#​7 0x00000000017dadf6 clang::ast_matchers::internal::(anonymous
namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively(clang::
ast_type_traits::DynTypedNode const&,
clang::ast_matchers::internal::DynTypedMatcher const&,
clang::ast_matchers::internal::BoundNodesTreeBuilder*,
clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode)
(./bin/clang-tidy+0x17dadf6)
#​8 0x00000000017db7f9 clang::ast_matchers::internal::(anonymous
namespace)::MatchASTVisitor::matchesAncestorOfRecursively(clang::
ast_type_traits::DynTypedNode const&,
clang::ast_matchers::internal::DynTypedMatcher const&,
clang::ast_matchers::internal::BoundNodesTreeBuilder*,
clang::ast_matchers::internal::ASTMatchFinder::AncestorMatchMode)
(./bin/clang-tidy+0x17db7f9)
(and so on)

Now the question is how practical is the code sample you posted? Is it
representative of the depth of AST in some real code? Since clang uses
recursion in multiple places, it's possible to create a code sample that
will lead to a stack overflow for any given stack size.

However, we could improve the stack usage on particular recursive call
paths, if the current state is problematic for real-world code.

The crash you are seeing here is most likely from upgrade-duration and not caused by this particular code. There is currently another issue open for that (but most likely fixed already, see llvm/llvm-bugzilla-archive#39949 ).

Does it crash for only the cat-* check?

The crash you are seeing here is most likely from upgrade-duration and not
caused by this particular code. There is currently another issue open for that
(but most likely fixed already, see llvm/llvm-bugzilla-archive#39949 ).

Does it crash for only the cat-* check?

There's a lot of evidence that the crash I am seeing is caused by stack overflows. First of all, the crash goes away if I increase the stack size limit. For a non-optimized build I found the maximum stack depth on this example to be around 21MB:
$ (ulimit -s 21848 ; clang-tidy -checks=-,abseil stack-overflow.cpp -- )
$ (ulimit -s 21847 ; clang-tidy -checks=-,abseil stack-overflow.cpp -- )
*** SIGSEGV (@0x7ffe1ffd6fe8); stack trace: ***
PC: @ 0x55a9fc1b70d2 (unknown) clang::ASTContext::ParentMap::getDynNodeFromMap<>()
@ 0x7f6665d379a0 (unknown) (unknown)
@ 0x55a9fc1af586 80 clang::ASTContext::ParentMap::getParents()
@ 0x55a9fc19ade0 80 clang::ASTContext::getParents()
@ 0x55a9fbbd0c4b 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ 0x55a9fbbd0e54 2096 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchesAncestorOfRecursively()
@ 0x55a9fbbd0b60 1808 clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::memoizedMatchesAncestorOfRecursively()
@ ... and at least 1000 more frames

The other thing is that there's a number of totally different combinations of checks that cause it (and I found no single check which does). It looks like certain combinations of matchers make memoization less efficient and cause deeper recursion. In any case, this can be addressed by moving large local variables in expensive recursion paths to a separate buffer.

Following Manuel's recommendation, I reduced the inline size of a SmallVector that happens multiple times on the relevant stack frames. As a result, the stack footprint has dropped significantly. The stack frames of the two methods (matchesAncestorOfRecursively and memoizedMatchesAncestorOfRecursively) have decreased from 2800 to 640 bytes (Linux x64, clang-tidy built with clang -O3).

I'll stop here, but if someone wants to improve this further, feel free to do so.

The relevant commit is r351196.

@​Trym Bremnes do you consider this bug as done?
The underlying issue (recursion itself) is not avoidable, but alex did commit a mitigation.

We could close this bug report then :)

@​Jonas Toth
I guess it as good as it gets. Thank you all for looking into this bug.