crash on deeply nested parentheses in input about castxml

[bradking]

I can reproduce the problem with a simple .c source with deeply nested parentheses:

enum E { X = ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+
1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1)+1) };

[bradking]

On Windows, running just castxml input.c, where input.c contains the deeply nested parentheses mentioned above, is enough to cause the problem.

On Linux, the same call fails with an error "fatal error: bracket nesting level exceeded maximum of 256", but it can be overcome with -fbracket-depth=500. Adding that option on Windows makes no difference.

[bradking]

Please strip xbd_win.h down to a minimal complete example input file that demonstrates the problem.

[jciena]

I do not see -fbracket-depth option in help. As you mentioned, in windows it makes no difference using it or not.
Should I report to llvm as asked in the error message below?

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: castxml.exe --castxml-gccxml -o output.xml --castxml-cc-msvc-c cl .\\input.c -fbracket-depth=1000
1.      .\input.c:1:194: current parser token '('

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: castxml.exe --castxml-gccxml -o output.xml --castxml-cc-msvc-c cl .\\input.c
1.      .\input.c:1:194: current parser token '('

[bradking]

We need to try building CastXML with the latest LLVM version before reporting it there.

[jciena]

I already raised it (link) there, and they suggested:

Could you please try 15 or main branch? https://godbolt.org/ should be helpful.

I will build using the main and test again.

[bradking]

Thanks. I think CastXML may need some updates to compile against LLVM/Clang 14 and/or 15. I'll look at that.

[jciena]

I appreciate your support.

[bradking]

CastXML builds cleanly against LLVM/Clang 14.0. However, the LLVM/Clang release/15.x branch currently has a regression that breaks CastXML. I've reported that as llvm/llvm-project#57483.

[bradking]

After hacking the LLVM/Clang 15.x install tree with this patch:

--- include/clang/Lex/Preprocessor.h.orig       2022-08-31 09:24:20.359922800 -0400
+++ include/clang/Lex/Preprocessor.h    2022-08-31 11:55:51.490578400 -0400
@@ -1353,6 +1353,8 @@
   StringRef getLastMacroWithSpelling(SourceLocation Loc,
                                      ArrayRef<TokenValue> Tokens) const;

+  const std::string &getPredefines() const { return Predefines; }
+
   /// Set the predefines for this Preprocessor.
   ///
   /// These predefines are automatically injected when parsing the main file.

then CastXML builds again and all tests pass.

However, the crash discussed here remains. I've got a Debug build, so I'll try to get a backtrace.

[bradking]

Clang's internal recursion overflows the stack before reaching the default -fbracket-depth=256 nesting level limit. I've posted more details in llvm/llvm-project#57456 (comment).

[bradking]

The problem doesn't occur in LLVM/Clang's own binaries because they are built with a larger stack: llvm/llvm-project#57456 (comment).

CastXML should be built with a larger stack too.

[bradking]

I've released CastXML 0.4.6 with this fix.

[jciena]

Thank you, I'll check it.
Much appreciated!