SIGSEGV in clang_getCursorPrettyPrinted() (or StmtPrinter::Visit(clang::Stmt*))

[0x6675636b796f75676974687562]

So, as I mentioned in the previous issue (#1437), I was calling clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData), now in a single-threaded mode.

We managed to successfully parse the code base of CMake, GNU Make, and OpenSSL.

When parsing the source code of Linux (5.18, if it matters), while in the middle of clang_getCursorPrettyPrinted(), we received a steadily reproducible SIGSEGV at

C  [libclang.so.16+0x86ac4a]  (anonymous namespace)::StmtPrinter::Visit(clang::Stmt*)+0x2a

StmtPrinter::Visit(clang::Stmt*) is a C++ call invoked internally by clang_getCursorPrettyPrinted().

The issue does not depend on the JVM vendor or version (versions 11 and 17 were tested).

[0x6675636b796f75676974687562]

hs_err_pid1692278.log
hs_err_pid1695811.log
hs_err_pid1697424.log
hs_err_pid1699043.log
hs_err_pid1700323.log

[saudet]

Please try again with the snapshots: http://bytedeco.org/builds/

[0x6675636b796f75676974687562]

@saudet, the same is true with snapshot versions, too.

What I managed to find out is that clang_getCursorPrettyPrinted() doesn't always work well for some CXCursor types, notably CXCursor_StructDecl and CXCursor_FunctionDecl. This means that sometimes correct struct or function bodies are returned, and sometimes the JVM process crashes.

Particularly, the following function declaration (from include/linux/slab.h, included in mm/slob.c) results in a crash:

void *__kmalloc(size_t size, gfp_t flags) __attribute__((__assume_aligned__(__alignof__(unsigned long long)))) __attribute__((__malloc__));

To be more specific, a function should return a void * and have the __assume_aligned__(__alignof__(unsigned long long)) attribute. So here's one of the minimal reproducers:

void *f() __attribute__((__assume_aligned__(__alignof__(unsigned long long))));

[0x6675636b796f75676974687562]

Forwarded upstream as:

• SIGSEGV in clang_getCursorPrettyPrinted() (or, precisely, StmtPrinter::Visit(clang::Stmt*)) llvm/llvm-project#75920