| Summary: | Repeated segfault in clang_getFileContents() after starting to declare a member function in a header | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Igor Kushnir <igorkuo> |
| Component: | Language Support: CPP (Clang-based) | Assignee: | kdevelop-bugs-null |
| Status: | CONFIRMED --- | ||
| Severity: | crash | CC: | git.ceeac |
| Priority: | NOR | ||
| Version First Reported In: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | gdb.txt with output of thread apply all bt | ||
|
Description
Igor Kushnir
2025-10-14 16:45:19 UTC
Created attachment 187795 [details]
gdb.txt with output of thread apply all bt
I've encountered this bug too (Arch Linux, kdevelop 6.4.251200 (25.12.0), clang 21.1.6).
KDevelop crashed when I added a new file with existing code (that does not compile) to my CMake project via target_add_sources, and now KDevelop crashes every time on startup.
Thread 31 "Queue(0x555555b" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff697fa6c0 (LWP 12356)]
0x00007fff99e994c2 in llvm::IntrusiveRefCntPtr<clang::SourceManager>::operator* () at /usr/include/llvm/ADT/IntrusiveRefCntPtr.h:203
203 T &operator*() const { return *Obj; }
After removing ~/.local/share/kdevelop/sessions/ and re-opening the project file, no crash occors on startup. However, KDevelop now crashes in the same location (llvm::IntrusiveRefCntPtr<clang::SourceManager>::operator*) when parsing /usr/include/spa-0.2/spa/utils/string.h, This header belongs to the libpipewire package, which is at version 1.4.9-2, and the header is included from my code via #include <pipewire/extensions/metadata.h> It does not matter if the cache is cleared or not. A possible fault of KDevelop is that `unit` is invalid. Can you call clang_getFileContents() with the same unit but another file just before the crash occurs in GDB? More likely this is a Clang bug. Reporting it would require reproducing without KDevelop. kdevelop/plugins/clang/tests/minimal_visitor.cpp can help. Or perhaps Clang's c-index-test as the message of https://commits.kde.org/kdevelop/f2ba281ef110edab6c071e229e14ae24baa08352 suggests. Also reducing code that triggers the crash would be useful. Can you pass non-null `line` and `column` pointers to clang_getFileLocation() in ClangUtils::getRawContents() and print them? Then based on the output just before the crash we might be able to create a small example that triggers the bug. (In reply to Igor Kushnir from comment #4) > Can you pass > non-null `line` and `column` pointers to clang_getFileLocation() in > ClangUtils::getRawContents() and print them? For example: CXFile rangeFile; unsigned int start, end; CXFile rangeFileEnd; unsigned int line, column; clang_getFileLocation(rangeStart, &rangeFile, &line, &column, &start); clang_getFileLocation(rangeEnd, &rangeFileEnd, &line, &column, &end); And print out all variables declared in this code snippet. I expect the pointers rangeFile and rangeFileEnd to be equal. |