Bug 438249 - fresh kdevelop build from git master source crashes while importing a project
Summary: fresh kdevelop build from git master source crashes while importing a project
Status: RESOLVED UPSTREAM
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: git master
Platform: Debian testing Linux
: HI crash
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords: drkonqi
: 431811 454685 455769 466791 466975 482109 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-06-08 13:02 UTC by Arthur Gruzauskas
Modified: 2024-03-01 11:19 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
New crash information added by DrKonqi (71.93 KB, text/plain)
2021-06-08 13:02 UTC, Arthur Gruzauskas
Details
New crash information added by DrKonqi (110.10 KB, text/plain)
2022-04-12 10:25 UTC, Andrei Slavoiu
Details
attachment-32215-0.html (6.40 KB, text/html)
2022-06-02 01:53 UTC, Arthur Gruzauskas
Details
attachment-20598-0.html (3.17 KB, text/html)
2022-06-02 14:13 UTC, Arthur Gruzauskas
Details
New crash information added by DrKonqi (114.87 KB, text/plain)
2022-06-07 12:01 UTC, Andrei Slavoiu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arthur Gruzauskas 2021-06-08 13:02:03 UTC
Application: kdevelop (5.6.40)

Qt Version: 5.15.2
Frameworks Version: 5.78.0
Operating System: Linux 5.10.0-7-amd64 x86_64
Windowing system: X11
Distribution: Debian GNU/Linux 11 (bullseye)

-- Information about the crash:
- What I was doing when the application crashed:

i used 'rm -r $HOME/.local/share/kdevelop/; rm -r /$HOME/.cache/kdevduchain/; rm $HOME/.config/kdeveloprc' to get rid of all state that I know about.

build kdevelop from git master source using a shell script that has worked for years. No missing Recommendations.

set my usual defaults in Settings. Then import a known project. Crashes while importing the project doing an initial source file parse.

Been crashing for months. The same project loaded into a clean environment like the first line above using KDevelop-5.6.1-x86_64.AppImage works fine. Been using the AppImage successfully for many months now.

The help page in the crash handler was not clear to me, but today worked out how to find the dbgsym files needed for this report.

I'm happy to help with any info or testing, I love kdevelop!

Arthur

The crash can be reproduced every time.

-- Backtrace (Reduced):
#4  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:405
#5  0x00007fbf02cd02d7 in APInt () at /build/llvm-toolchain-11-HMpQvg/llvm-toolchain-11-11.0.1/llvm/include/llvm/ADT/APInt.h:325
#6  APSInt () at /build/llvm-toolchain-11-HMpQvg/llvm-toolchain-11-11.0.1/llvm/include/llvm/ADT/APSInt.h:21
#7  EvaluateKnownConstInt() () at /build/llvm-toolchain-11-HMpQvg/llvm-toolchain-11-11.0.1/clang/lib/AST/ExprConstant.cpp:14368
#8  0x00007fbf02c76345 in getBitWidthValue() () at /build/llvm-toolchain-11-HMpQvg/llvm-toolchain-11-11.0.1/clang/lib/AST/Decl.cpp:4030


Possible duplicates by query: bug 436863, bug 434799, bug 431811, bug 410586, bug 386527.

Reported using DrKonqi
Comment 1 Arthur Gruzauskas 2021-06-08 13:02:06 UTC
Created attachment 139104 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.
Comment 2 Andrei Slavoiu 2022-04-12 10:25:38 UTC
Created attachment 148116 [details]
New crash information added by DrKonqi

kdevelop (5.7.211203 (21.12.3)) using Qt 5.15.3

- What I was doing when the application crashed:
The same KDevelop version previously built with llvm-13 parsed the project successfuly. After rebuilding with llvm-14, it started crashing every time it reached about 10% of the project.

-- Backtrace (Reduced):
#6  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:535
#7  0x00007fb3f9283bbb in llvm::APInt::APInt(llvm::APInt const&) (that=..., this=0x7fb3bb7fa470) at /usr/lib/llvm/14/include/llvm/ADT/APInt.h:157
#8  llvm::APSInt::APSInt(llvm::APSInt const&) (this=0x7fb3bb7fa470) at /usr/lib/llvm/14/include/llvm/ADT/APSInt.h:23
#9  clang::Expr::EvaluateKnownConstInt(clang::ASTContext const&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const (this=0x7fb3b1d99a28, Ctx=..., Diag=Diag@entry=0x0) at /usr/src/debug/sys-devel/clang-14.0.0-r1/clang/lib/AST/ExprConstant.cpp:15116
#10 0x00007fb3f91ec94f in clang::FieldDecl::getBitWidthValue(clang::ASTContext const&) const (this=<optimized out>, Ctx=<optimized out>) at /usr/src/debug/sys-devel/clang-14.0.0-r1/clang/lib/AST/Decl.cpp:4206
Comment 3 Igor Kushnir 2022-06-01 15:32:08 UTC
Judging by the common "getBitWidthValue" line in the backtraces, this and Bug 454685 are both duplicates of Bug 431811.

Strange that this crash affects only some users. And there is no clear LLVM version pattern:
* in Bug 431811 it occurred in LLVM 10 and disappeared in LLVM 11;
* in this bug on Arthur's system it occurred in system LLVM 11, but not in the AppImage with LLVM 10;
* in this bug on Andrei's system it was absent in LLVM 13, but appeared in LLVM 14.
* in Bug 454685 it occurs in LLVM 13.

Andrei Slavoiu, could you try the workaround that works for other reporters?
Comment 4 Andrei Slavoiu 2022-06-01 19:14:21 UTC
(In reply to Igor Kushnir from comment #3)
> Andrei Slavoiu, could you try the workaround that works for other reporters?

Hi, I assume the workaround was applying this patch:
--- kdevelop-22.04.1-orig/plugins/clang/duchain/builder.cpp     2022-06-01 21:11:28.907037431 +0300
+++ kdevelop-22.04.1/plugins/clang/duchain/builder.cpp  2022-06-01 21:12:48.177035132 +0300
@@ -1080,7 +1080,7 @@
 #endif
 
 #if CINDEX_VERSION_MINOR >= 16
-    decl->setBitWidth(clang_getFieldDeclBitWidth(cursor));
+    decl->setBitWidth(-1);
 #endif
 
     if (clang_isCursorDefinition(cursor)) {


In that case, I confirm that after rebuilding with it kdevelop was able to complete the background parsing.
Comment 5 Igor Kushnir 2022-06-01 19:25:45 UTC
> Hi, I assume the workaround was applying this patch:
Yes, thank you for confirming.

Since blaming some specific LLVM versions does not figure, we need to find something else in common that may be the root cause of this crash. The reporter of Bug 431811 indicated that the crash occurred with wxWidgets-3.1.4 but not wxWidgets-3.0.4. Arthur, Andrei, do your projects use wxWidgets? Also, when you write that the crash started occurring after an update/rebuild of KDevelop, were your projects or some libraries they use updated at the same time too?
Comment 6 Arthur Gruzauskas 2022-06-02 01:53:33 UTC
Created attachment 149386 [details]
attachment-32215-0.html

Igor,

I don't use wxWidgets.

What was installed before the crash with the latest debian kdevelop:

2022-05-29 17:57:53 install libkf5configqml5:amd64 <none> 5.94.0-3
2022-05-29 17:57:54 install libkf5kcmutilscore5:amd64 <none> 5.94.0-2
2022-05-31 01:06:36 install qtbase5-examples:amd64 <none> 5.15.2+dfsg-16+b1
2022-05-31 10:05:07 install libqt6multimedia6:amd64 <none> 6.2.4-2
2022-05-31 10:05:07 install libqt6multimediaquick6:amd64 <none> 6.2.4-2
2022-05-31 10:05:08 install libqt6multimediawidgets6:amd64 <none> 6.2.4-2
2022-05-31 10:05:08 install qt6-image-formats-plugins:amd64 <none> 6.2.4-2
2022-05-31 10:05:08 install qt6-multimedia-dev:amd64 <none> 6.2.4-2
2022-05-31 10:05:08 install qt6-xdgdesktopportal-platformtheme:amd64 
<none> 6.2.4+dfsg-5
2022-06-01 15:45:09 install libsnapd-glib1:amd64 <none> 1.60-1
2022-06-01 15:45:10 install kdevelop58-libs:amd64 <none> 4:22.04.1-2
2022-06-01 15:45:13 install libkf5prisonscanner5:amd64 <none> 5.94.0-2
2022-06-01 16:01:40 install kdevelop-dbgsym:amd64 <none> 4:22.04.1-2
2022-06-01 16:01:42 install kdevelop-pg-qt-dbgsym:amd64 <none> 2.2.1-2
2022-06-01 16:01:42 install plasma-kdevelop-dbgsym:amd64 <none> 4:22.04.1-2
2022-06-01 16:37:47 install kdevelop-data:all <none> 4:22.04.1-2
2022-06-01 16:37:47 install kdevelop58-libs:amd64 <none> 4:22.04.1-2
2022-06-01 16:37:48 install kdevelop:amd64 <none> 4:22.04.1-2
2022-06-01 16:37:48 install kdevelop-dbgsym:amd64 <none> 4:22.04.1-2
2022-06-01 16:37:49 install kdevelop58-libs-dbgsym:amd64 <none> 4:22.04.1-2
2022-06-01 16:51:11 install libclang-common-13-dev-dbgsym:amd64 <none> 
1:13.0.1-4
2022-06-01 16:51:11 install libclang1-13-dbgsym:amd64 <none> 1:13.0.1-4
2022-06-01 16:51:12 install libkf5threadweaver5-dbgsym:amd64 <none> 
5.94.0-1
2022-06-01 16:51:12 install libkf5xmlgui-bin-dbgsym:amd64 <none> 5.94.0-1
2022-06-01 16:51:12 install libkf5xmlgui-dev-dbgsym:amd64 <none> 5.94.0-1
2022-06-01 16:51:13 install libqt5dbus5-dbgsym:amd64 <none> 
5.15.2+dfsg-16+b1
2022-06-01 16:51:13 install libqt5qmlmodels5-dbgsym:amd64 <none> 
5.15.2+dfsg-10
2022-06-01 16:51:13 install libqt5qmlworkerscript5-dbgsym:amd64 <none> 
5.15.2+dfsg-10
2022-06-01 16:51:13 install libqt5widgets5-dbgsym:amd64 <none> 
5.15.2+dfsg-16+b1
2022-06-01 16:51:13 install libusbmuxd6-dbgsym:amd64 <none> 2.0.2-3
2022-06-01 16:51:13 install qml-module-qtquick-xmllistmodel-dbgsym:amd64 
<none> 5.15.2-3

Arthur

On 2/6/22 5:25 am, Igor Kushnir wrote:
> https://bugs.kde.org/show_bug.cgi?id=438249
>
> --- Comment #5 from Igor Kushnir<igorkuo@gmail.com>  ---
>> Hi, I assume the workaround was applying this patch:
> Yes, thank you for confirming.
>
> Since blaming some specific LLVM versions does not figure, we need to find
> something else in common that may be the root cause of this crash. The reporter
> of Bug 431811 indicated that the crash occurred with wxWidgets-3.1.4 but not
> wxWidgets-3.0.4. Arthur, Andrei, do your projects use wxWidgets? Also, when you
> write that the crash started occurring after an update/rebuild of KDevelop,
> were your projects or some libraries they use updated at the same time too?
>
On 2/6/22 5:25 am, Igor Kushnir wrote:
> https://bugs.kde.org/show_bug.cgi?id=438249
>
> --- Comment #5 from Igor Kushnir<igorkuo@gmail.com>  ---
>> Hi, I assume the workaround was applying this patch:
> Yes, thank you for confirming.
>
> Since blaming some specific LLVM versions does not figure, we need to find
> something else in common that may be the root cause of this crash. The reporter
> of Bug 431811 indicated that the crash occurred with wxWidgets-3.1.4 but not
> wxWidgets-3.0.4. Arthur, Andrei, do your projects use wxWidgets? Also, when you
> write that the crash started occurring after an update/rebuild of KDevelop,
> were your projects or some libraries they use updated at the same time too?
>
Comment 7 Igor Kushnir 2022-06-02 07:12:34 UTC
Could someone try to get the backtrace of this crash with assertions enabled? (NDEBUG not defined)
When I navigate through the crash call stacks from https://code.woboq.org/llvm/clang/tools/libclang/CXType.cpp.html#374, I see several assert() calls, especially here: https://code.woboq.org/llvm/clang/lib/AST/ExprConstant.cpp.html#_ZNK5clang4Expr21EvaluateKnownConstIntERKNS_10ASTContextEPN4llvm15SmallVectorImplISt4pairINS_14SourceLocationENS_17PartialDiagnosticEEEE
Comment 8 Igor Kushnir 2022-06-02 07:13:26 UTC
(In reply to Igor Kushnir from comment #7)
> Could someone try to get the backtrace of this crash with assertions
> enabled? (NDEBUG not defined)
I mean: assertions enabled/NDEBUG not defined while building Clang.
Comment 9 Igor Kushnir 2022-06-02 07:32:06 UTC
*** Bug 454685 has been marked as a duplicate of this bug. ***
Comment 10 Igor Kushnir 2022-06-02 07:33:33 UTC
*** Bug 431811 has been marked as a duplicate of this bug. ***
Comment 11 Andrei Slavoiu 2022-06-02 11:16:28 UTC
(In reply to Igor Kushnir from comment #5)
> Arthur, Andrei, do your projects use wxWidgets?
No

> Also, when you write that the crash started occurring after an
> update/rebuild of KDevelop, were your projects or some libraries
> they use updated at the same time too?
I don't remember any significant code changes around that time.
But I could downgrade to the version built with clang-13 and see how it behaves with current code.

(In reply to Igor Kushnir from comment #7)
> Could someone try to get the backtrace of this crash with assertions
> enabled? (NDEBUG not defined)
I'll give it a try.
Comment 12 Arthur Gruzauskas 2022-06-02 14:13:07 UTC
Created attachment 149403 [details]
attachment-20598-0.html

Hi Igor,

Delays in responding to your problem solving request.

Having issues trying to compile clang13 with debian  'apt build-dep', 
which is my first approach as I am somewhat familiar with it.

=> "No ffs implementation found" is the current temporary roadblock. My 
problem, not yours. Unless you already know an obvious solution, of course.

I'm not after any hand holding, I am not just presenting you with the 
original issue and then whining at every small roadblock and then going 
away leaving you with my problem. I'm just saying your request for a 
debugging clang13 requires me to to fill in my own gaps in knowledge, 
which will take as long as it takes.

My motivation is I want a native kdevelop, not some bloody AppImage!

Sorry for the waffling, you can always skim past it 😉

Arthur, who babbles when on an intellectual hunt


On 2/6/22 5:12 pm, Igor Kushnir wrote:
> https://bugs.kde.org/show_bug.cgi?id=438249
>
> --- Comment #7 from Igor Kushnir<igorkuo@gmail.com>  ---
> Could someone try to get the backtrace of this crash with assertions enabled?
> (NDEBUG not defined)
> When I navigate through the crash call stacks from
> https://code.woboq.org/llvm/clang/tools/libclang/CXType.cpp.html#374, I see
> several assert() calls, especially here:
> https://code.woboq.org/llvm/clang/lib/AST/ExprConstant.cpp.html#_ZNK5clang4Expr21EvaluateKnownConstIntERKNS_10ASTContextEPN4llvm15SmallVectorImplISt4pairINS_14SourceLocationENS_17PartialDiagnosticEEEE
>
Comment 13 Igor Kushnir 2022-06-02 14:28:19 UTC
> Delays in responding to your problem solving request.
This is not an urgent request. No need to apologize for a delay so verbosely :)

>  "No ffs implementation found"
No idea about this, sorry.
Comment 14 Andrei Slavoiu 2022-06-02 17:01:53 UTC
Here is the assert. For some reason DrKonqi does not handle it, so I got the stacktrace manually:

kdevelop: /var/tmp/portage/sys-devel/clang-14.0.4/work/clang/lib/AST/ExprConstant.cpp:15103: llvm::APSInt clang::Expr::EvaluateKnownConstInt(const clang::ASTContext&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const: Assertion `!isValueDependent() && "Expression evaluator can't be called on a dependent expression."' failed.

Thread 41 "Queue(0x555558c" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff41560640 (LWP 24484)]
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44            return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff5f77d1f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff5f2aa62 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff5f15469 in __GI_abort () at abort.c:79
#4  0x00007ffff5f15395 in __assert_fail_base
    (fmt=0x7ffff60a3c80 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fff4f2c2c98 "!isValueDependent() && \"Expression evaluator can't be called on a dependent expression.\"", file=0x7fff4f2c53b0 "/var/tmp/portage/sys-devel/clang-14.0.4/work/clang/lib/AST/ExprConstant.cpp", line=15103, function=<optimized out>) at assert.c:92
#5  0x00007ffff5f239d2 in __GI___assert_fail
    (assertion=0x7fff4f2c2c98 "!isValueDependent() && \"Expression evaluator can't be called on a dependent expression.\"", file=0x7fff4f2c53b0 "/var/tmp/portage/sys-devel/clang-14.0.4/work/clang/lib/AST/ExprConstant.cpp", line=15103, function=0x7fff4f2cf7f0 "llvm::APSInt clang::Expr::EvaluateKnownConstInt(const clang::ASTContext&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const") at assert.c:101
#6  0x00007fff4de82d71 in clang::Expr::EvaluateKnownConstInt(clang::ASTContext const&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const (this=<optimized out>, Ctx=<optimized out>, Diag=Diag@entry=0x0)
    at /usr/src/debug/sys-devel/clang-14.0.4/clang/lib/AST/ExprConstant.cpp:15103
#7  0x00007fff4ddc979b in clang::FieldDecl::getBitWidthValue(clang::ASTContext const&) const (this=<optimized out>, Ctx=<optimized out>) at /usr/src/debug/sys-devel/clang-14.0.4/clang/lib/AST/Decl.cpp:4206
#8  0x00007fff4fcc1bff in (anonymous namespace)::Visitor::setDeclData<(CXCursorKind)6>(CXCursor, KDevelop::ClassMemberDeclaration*) (cursor=..., decl=decl@entry=0x7fff2a075a00, this=0x7fff4155efa0) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:1083
#9  0x00007fff4fcd346a in (anonymous namespace)::Visitor::createDeclarationCommon<(CXCursorKind)6, KDevelop::ClassMemberDeclaration>(CXCursor, KDevelop::Identifier const&) (this=this@entry=0x7fff4155efa0, cursor=..., id=...)
    at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:442
#10 0x00007fff4fcd404b in (anonymous namespace)::Visitor::createDeclaration<(CXCursorKind)6, KDevelop::ClassMemberDeclaration> (context=0x0, id=..., cursor=..., this=0x7fff4155efa0) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:451
#11 (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)6, KDevelop::ClassMemberDeclaration, false>(CXCursor) (this=this@entry=0x7fff4155efa0, cursor=...) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:1217
#12 0x00007fff4fcd5010 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)6> (parent=..., cursor=..., this=0x7fff4155efa0) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:965
#13 (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7fff4155efa0) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:1554
#14 0x00007fff4dccd9c5 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7fff4155e580, Cursor=..., CheckedRegionOfInterest=<optimized out>) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:220
#15 0x00007fff4dcd3add in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7fff4155e580, D=0x7ffec0bfc4c0) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:682
#16 0x00007fff4dcd3bd0 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7fff4155e580, DC=0x7ffec0bfc088) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:643
#17 0x00007fff4dccd2b2 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7fff4155e580, Cursor=...) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:509
#18 0x00007fff4dccd899 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=<optimized out>, client_data=<optimized out>) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:4578
#19 0x00007fff4fcca3d1 in (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)31, KDevelop::ClassDeclaration, true>(CXCursor) (this=0x7fff4155efa0, cursor=...) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:1214
#20 0x00007fff4fcd5c17 in (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7fff4155efa0) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:1570
#21 0x00007fff4dccd9c5 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7fff4155ed70, Cursor=..., CheckedRegionOfInterest=<optimized out>) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:220
#22 0x00007fff4dcd3add in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7fff4155ed70, D=0x7ffec0bfc0d8) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:682
#23 0x00007fff4dcd3bd0 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7fff4155ed70, DC=0x7ffec14fe720) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:643
#24 0x00007fff4dccd703 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7fff4155ed70, Cursor=...) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:543
#25 0x00007fff4dccd899 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=<optimized out>, client_data=<optimized out>) at /usr/src/debug/sys-devel/clang-14.0.4/clang/tools/libclang/CIndex.cpp:4578
#26 0x00007fff4fcc6929 in (anonymous namespace)::Visitor::Visitor (update=196, includes=..., file=0x2a, tu=<optimized out>, this=0x7fff4155efa0) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:1471
#27 Builder::visit(CXTranslationUnitImpl*, void*, QHash<void*, KDevelop::ReferencedTopDUContext> const&, bool) (tu=<optimized out>, file=file@entry=0x7ffec08d4a80, includes=..., update=update@entry=false) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/builder.cpp:1618
#28 0x00007fff4fce199e in ClangHelpers::buildDUChain(void*, QMultiHash<void*, Import> const&, ParseSession const&, QFlags<KDevelop::TopDUContext::Feature>, QHash<void*, KDevelop::ReferencedTopDUContext>&, QHash<KDevelop::IndexedString, KDevelop::ModificationRevision> const&, KDevelop::IndexedString const&, ClangIndex*, std::function<bool ()> const&) (file=<optimized out>, imports=..., session=..., features=..., features@entry=..., includedFiles=..., unsavedRevisions=..., parseDocument=..., index=0x5555599103f0, abortFunction=...)
    at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/duchain/clanghelpers.cpp:207
#29 0x00007fff4fd79430 in ClangParseJob::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) (this=<optimized out>) at /usr/src/debug/dev-util/kdevelop-22.04.1/kdevelop-22.04.1/plugins/clang/clangparsejob.cpp:326
#30 0x00007ffff2b74aa9 in ThreadWeaver::IdDecorator::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) (this=<optimized out>, self=..., thread=0x7fff340025e0) at /usr/src/debug/kde-frameworks/threadweaver-5.94.0/threadweaver-5.94.0/src/iddecorator.cpp:50
#31 0x00007ffff2b746f7 in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) (this=<optimized out>, job=<optimized out>, thread=<optimized out>) at /usr/src/debug/kde-frameworks/threadweaver-5.94.0/threadweaver-5.94.0/src/executor.cpp:33
#32 0x00007ffff2b75550 in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) (this=<optimized out>, self=..., th=0x7fff340025e0) at /usr/src/debug/kde-frameworks/threadweaver-5.94.0/threadweaver-5.94.0/src/job.cpp:64
#33 0x00007ffff2b79b02 in ThreadWeaver::Thread::run() (this=0x7fff340025e0) at /usr/src/debug/kde-frameworks/threadweaver-5.94.0/threadweaver-5.94.0/src/thread.cpp:98
#34 0x00007ffff645b8a9 in QThreadPrivate::start(void*) (arg=0x7fff340025e0) at /usr/src/debug/dev-qt/qtcore-5.15.4-r2/qtbase-everywhere-src-5.15.4/src/corelib/thread/qthread_unix.cpp:331
#35 0x00007ffff5f75f6a in start_thread (arg=<optimized out>) at pthread_create.c:442
#36 0x00007ffff5ffb28c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Comment 15 Igor Kushnir 2022-06-02 18:34:14 UTC
> Assertion `!isValueDependent() && "Expression evaluator can't be called on a dependent expression."' failed.
Thanks for checking this so quickly!
This must really be an upstream libclang bug because clang_getFieldDeclBitWidth() has no preconditions. From https://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#ga80bbb872dde5b2f26964081338108f91:
> CINDEX_LINKAGE int clang_getFieldDeclBitWidth(CXCursor C) 	
> Retrieve the bit width of a bit field declaration as an integer.
> If a cursor that is not a bit field declaration is passed in, -1 is returned.
In order to report the libclang bug, we need to figure out which data member of which class causes it first. Can someone try inserting the line `qCritical() << "setDeclData" << decl->toString() << decl->comment();` just above the crashing `decl->setBitWidth` line in KDevelop's builder.cpp, reproduce the crash and hopefully determine a minimum reproducible example based on the last "setDeclData" line printed before the crash?

Note that `decl->toString()` returns the type and the name of the data member and `decl->comment()` returns the data member's associated documentation. Also note that KDevelop parses data members of a class in order, so the lines immediately preceding the last one before the crash could help identify the class and the data member that causes the crash.
Comment 16 Andrei Slavoiu 2022-06-02 19:49:38 UTC
Looks like it's parsing std::string when crashing?!?!

[Thread 0x7ffec67fc640 (LWP 2174) exited]
setDeclData "class basic_string_base< Allocator >" ""
setDeclData "<notype> operator=" ""
setDeclData "<notype> basic_string_base<Allocator>" ""
setDeclData "<notype> allocator_type" ""
setDeclData "<notype> allocator_traits_type" ""
setDeclData "<notype> stored_allocator_type" ""
setDeclData "<notype> pointer" ""
setDeclData "<notype> value_type" ""
setDeclData "<notype> size_type" ""
setDeclData "<notype> difference_type" ""
setDeclData "<notype> pointer_traits" ""
setDeclData "<notype> basic_string_base<Allocator>" ""
setDeclData "<notype> basic_string_base<Allocator>" ""
setDeclData "<notype> basic_string_base<Allocator>" ""
setDeclData "<notype> basic_string_base<Allocator>" ""
setDeclData "<notype> basic_string_base<Allocator>" ""
setDeclData "<notype> ~basic_string_base<Allocator>" ""
setDeclData "class long_t" ""
setDeclData "<notype> is_short" ""
setDeclData "<notype> length" ""
[New Thread 0x7ffec67fc640 (LWP 2208)]
kdevelop: /var/tmp/portage/sys-devel/clang-14.0.4/work/clang/lib/AST/ExprConstant.cpp:15103: llvm::APSInt clang::Expr::EvaluateKnownConstInt(const clang::ASTContext&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const: Assertion `!isValueDependent() && "Expression evaluator can't be called on a dependent expression."' failed.
Comment 17 Andrei Slavoiu 2022-06-02 19:54:16 UTC
No, not std::string. boost::string. Found the culprit:

  //This is the structure controlling a long string
   struct long_t
   {
      size_type      is_short  : 1;
      size_type      length    : (sizeof(size_type)*CHAR_BIT - 1);
Comment 18 Andrei Slavoiu 2022-06-03 16:59:57 UTC
And another correction, it's boost::container::string. Looks like boost has multiple string implementations.

Also, I compiled kdevelop with clang-13 again, and no more crash. Weird.
Comment 19 Igor Kushnir 2022-06-04 10:45:40 UTC
(In reply to Andrei Slavoiu from comment #17)
> No, not std::string. boost::string. Found the culprit:
> 
>   //This is the structure controlling a long string
>    struct long_t
>    {
>       size_type      is_short  : 1;
>       size_type      length    : (sizeof(size_type)*CHAR_BIT - 1);
> And another correction, it's boost::container::string. Looks like boost has multiple string implementations.
Apparently Clang 14 considers the bit width of long_t::length value-dependent. Perhaps clang::FieldDecl::getBitWidthValue() should check if the bit width is value-dependent before calling Expr::EvaluateKnownConstInt(). Or perhaps clang_getFieldDeclBitWidth() should check that. If you can reproduce the crash consistently with Clang 14 (I cannot with my system Clang 13), report the bug.

> Also, I compiled kdevelop with clang-13 again, and no more crash. Weird.
Does KDevelop compiled against Clang 13 call Clang 14 implementation at runtime or does it keep using the Clang 13 version it was compiled against?
Comment 20 Andrei Slavoiu 2022-06-06 13:24:28 UTC
(In reply to Igor Kushnir from comment #19)
> If you can reproduce the crash consistently with Clang 14
> (I cannot with my system Clang 13), report the bug.
Yes, it crashes consistently with clang 14, I'll look into reporting the bug upstream.

> Does KDevelop compiled against Clang 13 call Clang 14 implementation at
> runtime or does it keep using the Clang 13 version it was compiled against?
Gentoo puts the libraries of each clang version in it's own dir, so it keeps using the one it was built with:
# ldd /usr/lib64/qt5/plugins/kdevplatform/36/kdevclangsupport.so | grep llvm
        libclang.so.13 => /usr/lib/llvm/13/lib64/libclang.so.13 (0x00007f3303933000)
        libLLVM-13.so => /usr/lib/llvm/13/lib64/../lib64/libLLVM-13.so (0x00007f32fafd9000)
After adjusting the symlinks from llvm/13 to point to the ones in llvm/14, kdevelop built with clang-13 and ran with clang-14 crashes the same way as the one built with clnag-14.
Comment 21 Igor Kushnir 2022-06-06 13:29:53 UTC
If you want to play with this some more, you could try building Clang 13 with assertions enabled and see if the assertion is triggered. If yes, then the absence of the crash is accidental. If the assertion does not fail, then maybe it's a regression in Clang 14.
Comment 22 Andrei Slavoiu 2022-06-06 18:23:46 UTC
(In reply to Igor Kushnir from comment #21)
> If you want to play with this some more, you could try building Clang 13
> with assertions enabled and see if the assertion is triggered. If yes, then
> the absence of the crash is accidental. If the assertion does not fail, then
> maybe it's a regression in Clang 14.

Hah, good point. The assert fails on clang-13 as well when built with DEBUG. Probably on 13 it just happened to return some junk instead of crashing.
Comment 23 Igor Kushnir 2022-06-07 11:02:16 UTC
> Hah, good point. The assert fails on clang-13 as well when built with DEBUG.
> Probably on 13 it just happened to return some junk instead of crashing.
What bit width does it return?

> Perhaps clang::FieldDecl::getBitWidthValue() should check if the bit width is value-dependent before calling Expr::EvaluateKnownConstInt().
> Or perhaps clang_getFieldDeclBitWidth() should check that.
You can attempt to fix the bug yourself with placing a check in one of these two functions.
Comment 24 Andrei Slavoiu 2022-06-07 12:01:39 UTC
Created attachment 149527 [details]
New crash information added by DrKonqi

kdevelop (5.8.220401 (22.04.1)) using Qt 5.15.4

- What I was doing when the application crashed:
Compiled clang-13 back without DEBUG and now I get the same crash with it as well.

-- Backtrace (Reduced):
#6  0x00007fc50833d030 in __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:801
#7  0x00007fc45184af1b in llvm::APInt::APInt(llvm::APInt const&) (that=..., this=0x7fc41e7f82c0) at /usr/lib/llvm/13/include/llvm/ADT/APInt.h:321
#8  llvm::APSInt::APSInt(llvm::APSInt const&) (this=0x7fc41e7f82c0) at /usr/lib/llvm/13/include/llvm/ADT/APSInt.h:22
#9  clang::Expr::EvaluateKnownConstInt(clang::ASTContext const&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const (this=0x7fc2d0226918, Ctx=..., Diag=Diag@entry=0x0) at /usr/src/debug/sys-devel/clang-13.0.1/clang/lib/AST/ExprConstant.cpp:15006
#10 0x00007fc4517b449f in clang::FieldDecl::getBitWidthValue(clang::ASTContext const&) const (this=<optimized out>, Ctx=<optimized out>) at /usr/src/debug/sys-devel/clang-13.0.1/clang/lib/AST/Decl.cpp:4172
Comment 25 Igor Kushnir 2022-06-07 13:07:43 UTC
> Compiled clang-13 back without DEBUG and now I get the same crash with it as
> well.
Perhaps the crash started occurring because of the toolchain (g++/libstdc++/glibc) upgrade or different comper flags, not Clang upgrade. So when Clang 13 was recompiled against the newer toolchain version, the crash appeared. But in any case Clang's assertion fails, so it is probably a Clang bug.
Comment 26 Igor Kushnir 2022-06-22 19:03:10 UTC
*** Bug 455769 has been marked as a duplicate of this bug. ***
Comment 27 Arthur Gruzauskas 2023-02-28 04:33:57 UTC
Have been using kdevelop git master successfully for the last 8 months with the following patch suggested by Igor:

---------------------------------------------------------------------------------------------------------------------------------------------------------------
--- kdevelop-22.04.1-orig/plugins/clang/duchain/builder.cpp     2022-06-01 21:11:28.907037431 +0300
+++ kdevelop-22.04.1/plugins/clang/duchain/builder.cpp  2022-06-01 21:12:48.177035132 +0300
@@ -1080,7 +1080,7 @@
 #endif
 
 #if CINDEX_VERSION_MINOR >= 16
-    decl->setBitWidth(clang_getFieldDeclBitWidth(cursor));
+    decl->setBitWidth(-1);
 #endif
 
     if (clang_isCursorDefinition(cursor)) {
---------------------------------------------------------------------------------------------------------------------------------------------------------------

The other day had to reinstall Debian testing, and again the same crash on a freshly compiled kdevelop git master doing an initial source parse. The above patch worked yet again.

Happy to supply any info, or do any suggested bug hunting.
Comment 28 Igor Kushnir 2023-02-28 05:33:36 UTC
(In reply to Arthur Gruzauskas from comment #27)
> Happy to supply any info, or do any suggested bug hunting.
Someone has to propose a LLVM fix and get it in. I plan to do so if I manage to reproduce the bug locally. But not sure when I get to it.
Comment 29 Igor Kushnir 2023-03-04 06:54:08 UTC
*** Bug 466791 has been marked as a duplicate of this bug. ***
Comment 30 Igor Kushnir 2023-03-06 08:29:04 UTC
Managed to reproduce the assertion failure in KDevelop master built against fresh libclang version 17.0.0-git by opening the file /usr/include/boost/container/string.hpp in a session containing a couple of tiny projects and waiting for the background parser to parse this file. Found the upstream bug https://github.com/llvm/llvm-project/issues/56644 and mentioned this KDevelop crash in a comment to it.

The backtrace:
*** Program received signal SIGABRT (Aborted) ***
#0 0x00007f42848a08ec in () at /usr/lib/libc.so.6
#1 0x00007f4284851ea8 in raise () at /usr/lib/libc.so.6
#2 0x00007f428483b53d in abort () at /usr/lib/libc.so.6
#3 0x00007f428483b45c in () at /usr/lib/libc.so.6
#4 0x00007f428484a9f6 in () at /usr/lib/libc.so.6
#5 0x00007f421116303d in clang::Expr::EvaluateKnownConstInt(clang::ASTContext const&, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >*) const (this=<optimized out>, Ctx=<optimized out>, Diag=Diag@entry=0x0) at llvm-project/clang/lib/AST/ExprConstant.cpp:15473
#6 0x00007f421104e7a5 in clang::FieldDecl::getBitWidthValue(clang::ASTContext const&) const (this=<optimized out>, Ctx=<optimized out>) at llvm-project/clang/lib/AST/Decl.cpp:4309
#7 0x00007f421b0b972b in (anonymous namespace)::Visitor::setDeclData<(CXCursorKind)6>(CXCursor, KDevelop::ClassMemberDeclaration*) const (this=0x7f421a702ff0, cursor=..., decl=0x7f420202d170) at kdevelop/plugins/clang/duchain/builder.cpp:1159
#8 0x00007f421b0a6d4a in (anonymous namespace)::Visitor::createDeclarationCommon<(CXCursorKind)6, KDevelop::ClassMemberDeclaration>(CXCursor, KDevelop::Identifier const&) (this=0x7f421a702ff0, cursor=..., id=...) at kdevelop/plugins/clang/duchain/builder.cpp:445
#9 0x00007f421b09a789 in (anonymous namespace)::Visitor::createDeclaration<(CXCursorKind)6, KDevelop::ClassMemberDeclaration>(CXCursor, KDevelop::Identifier const&, KDevelop::DUContext*) (this=0x7f421a702ff0, cursor=..., id=..., context=0x0) at kdevelop/plugins/clang/duchain/builder.cpp:456
#10 0x00007f421b093591 in (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)6, KDevelop::ClassMemberDeclaration, false>(CXCursor) (this=0x7f421a702ff0, cursor=...) at kdevelop/plugins/clang/duchain/builder.cpp:1293
#11 0x00007f421b088e99 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)6>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:1009
#12 0x00007f421b082309 in (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7f421a702ff0) at kdevelop/plugins/clang/duchain/builder.cpp:1675
#13 0x00007f4210f2b400 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7f421a700ec0, Cursor=..., CheckedRegionOfInterest=<optimized out>) at llvm-project/clang/tools/libclang/CIndex.cpp:220
#14 0x00007f4210f31e66 in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7f421a700ec0, D=0x7f41e0443490) at llvm-project/clang/tools/libclang/CIndex.cpp:682
#15 0x00007f4210f32021 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7f421a700ec0, DC=0x7f41e0443148) at llvm-project/clang/tools/libclang/CIndex.cpp:643
#16 0x00007f4210f2aca8 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7f421a700ec0, Cursor=...) at llvm-project/clang/tools/libclang/CIndex.cpp:509
#17 0x00007f4210f2b2c1 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=0x7f421b081f0f <(anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData)>, client_data=0x7f421a702ff0) at llvm-project/clang/tools/libclang/CIndex.cpp:4827
#18 0x00007f421b0a42f8 in (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)2, KDevelop::ClassDeclaration, true>(CXCursor) (this=0x7f421a702ff0, cursor=...) at kdevelop/plugins/clang/duchain/builder.cpp:1290
#19 0x00007f421b0999dd in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)2, (Decision)0, (Decision)0>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:1009
#20 0x00007f421b092ac7 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)2, (Decision)0, (Decision)2>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:984
#21 0x00007f421b088a79 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)2>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:972
#22 0x00007f421b082185 in (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7f421a702ff0) at kdevelop/plugins/clang/duchain/builder.cpp:1671
#23 0x00007f4210f2b400 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7f421a701540, Cursor=..., CheckedRegionOfInterest=<optimized out>) at llvm-project/clang/tools/libclang/CIndex.cpp:220
#24 0x00007f4210f31e66 in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7f421a701540, D=0x7f41e0443108) at llvm-project/clang/tools/libclang/CIndex.cpp:682
#25 0x00007f4210f32021 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7f421a701540, DC=0x7f41e13ee650) at llvm-project/clang/tools/libclang/CIndex.cpp:643
#26 0x00007f4210f2aca8 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7f421a701540, Cursor=...) at llvm-project/clang/tools/libclang/CIndex.cpp:509
#27 0x00007f4210f2b2c1 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=0x7f421b081f0f <(anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData)>, client_data=0x7f421a702ff0) at llvm-project/clang/tools/libclang/CIndex.cpp:4827
#28 0x00007f421b0afcf2 in (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)31, KDevelop::ClassDeclaration, true>(CXCursor) (this=0x7f421a702ff0, cursor=...) at kdevelop/plugins/clang/duchain/builder.cpp:1290
#29 0x00007f421b09f967 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)31, (Decision)1, (Decision)0>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:1009
#30 0x00007f421b09591f in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)31, (Decision)1, (Decision)2>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:984
#31 0x00007f421b089d9f in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)31>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:973
#32 0x00007f421b082919 in (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7f421a702ff0) at kdevelop/plugins/clang/duchain/builder.cpp:1691
#33 0x00007f4210f2b400 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7f421a701bc0, Cursor=..., CheckedRegionOfInterest=<optimized out>) at llvm-project/clang/tools/libclang/CIndex.cpp:220
#34 0x00007f4210f31e66 in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7f421a701bc0, D=0x7f41e13ee6b8) at llvm-project/clang/tools/libclang/CIndex.cpp:682
#35 0x00007f4210f32021 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7f421a701bc0, DC=0x7f41e13ee510) at llvm-project/clang/tools/libclang/CIndex.cpp:643
#36 0x00007f4210f2aca8 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7f421a701bc0, Cursor=...) at llvm-project/clang/tools/libclang/CIndex.cpp:509
#37 0x00007f4210f2b2c1 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=0x7f421b081f0f <(anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData)>, client_data=0x7f421a702ff0) at llvm-project/clang/tools/libclang/CIndex.cpp:4827
#38 0x00007f421b0942da in (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)22, KDevelop::Declaration, true>(CXCursor) (this=0x7f421a702ff0, cursor=...) at kdevelop/plugins/clang/duchain/builder.cpp:1290
#39 0x00007f421b089571 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)22>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:1009
#40 0x00007f421b0825b0 in (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7f421a702ff0) at kdevelop/plugins/clang/duchain/builder.cpp:1682
#41 0x00007f4210f2b400 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7f421a702160, Cursor=..., CheckedRegionOfInterest=<optimized out>) at llvm-project/clang/tools/libclang/CIndex.cpp:220
#42 0x00007f4210f31e66 in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7f421a702160, D=0x7f41e13ee4e0) at llvm-project/clang/tools/libclang/CIndex.cpp:682
#43 0x00007f4210f32021 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7f421a702160, DC=0x7f41e13edba0) at llvm-project/clang/tools/libclang/CIndex.cpp:643
#44 0x00007f4210f2aca8 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7f421a702160, Cursor=...) at llvm-project/clang/tools/libclang/CIndex.cpp:509
#45 0x00007f4210f2b2c1 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=0x7f421b081f0f <(anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData)>, client_data=0x7f421a702ff0) at llvm-project/clang/tools/libclang/CIndex.cpp:4827
#46 0x00007f421b0942da in (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)22, KDevelop::Declaration, true>(CXCursor) (this=0x7f421a702ff0, cursor=...) at kdevelop/plugins/clang/duchain/builder.cpp:1290
#47 0x00007f421b089571 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)22>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:1009
#48 0x00007f421b0825b0 in (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7f421a702ff0) at kdevelop/plugins/clang/duchain/builder.cpp:1682
#49 0x00007f4210f2b400 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7f421a702700, Cursor=..., CheckedRegionOfInterest=<optimized out>) at llvm-project/clang/tools/libclang/CIndex.cpp:220
#50 0x00007f4210f31e66 in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7f421a702700, D=0x7f41e13edb70) at llvm-project/clang/tools/libclang/CIndex.cpp:682
#51 0x00007f4210f32021 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7f421a702700, DC=0x7f41e09c8590) at llvm-project/clang/tools/libclang/CIndex.cpp:643
#52 0x00007f4210f2aca8 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7f421a702700, Cursor=...) at llvm-project/clang/tools/libclang/CIndex.cpp:509
#53 0x00007f4210f2b2c1 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=0x7f421b081f0f <(anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData)>, client_data=0x7f421a702ff0) at llvm-project/clang/tools/libclang/CIndex.cpp:4827
#54 0x00007f421b0942da in (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)22, KDevelop::Declaration, true>(CXCursor) (this=0x7f421a702ff0, cursor=...) at kdevelop/plugins/clang/duchain/builder.cpp:1290
#55 0x00007f421b089571 in (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)22>(CXCursor, CXCursor) (this=0x7f421a702ff0, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:1009
#56 0x00007f421b0825b0 in (anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData) (cursor=..., parent=..., data=0x7f421a702ff0) at kdevelop/plugins/clang/duchain/builder.cpp:1682
#57 0x00007f4210f2b400 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) (this=0x7f421a702ca0, Cursor=..., CheckedRegionOfInterest=<optimized out>) at llvm-project/clang/tools/libclang/CIndex.cpp:220
#58 0x00007f4210f31e66 in clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) (this=0x7f421a702ca0, D=0x7f41e09c8560) at llvm-project/clang/tools/libclang/CIndex.cpp:682
#59 0x00007f4210f32021 in clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) (this=0x7f421a702ca0, DC=0x7f41e0d42840) at llvm-project/clang/tools/libclang/CIndex.cpp:643
#60 0x00007f4210f2b118 in clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) (this=0x7f421a702ca0, Cursor=...) at llvm-project/clang/tools/libclang/CIndex.cpp:543
#61 0x00007f4210f2b2c1 in clang_visitChildren(CXCursor, CXCursorVisitor, CXClientData) (parent=..., visitor=0x7f421b081f0f <(anonymous namespace)::visitCursor(CXCursor, CXCursor, CXClientData)>, client_data=0x7f421a702ff0) at llvm-project/clang/tools/libclang/CIndex.cpp:4827
#62 0x00007f421b0818b0 in (anonymous namespace)::Visitor::Visitor(CXTranslationUnit, CXFile, IncludeFileContexts const&, bool) (this=0x7f421a702ff0, tu=0x7f41e015b5f0, file=0x7f41e1364bf0, includes=QHash<void *, KDevelop::ReferencedTopDUContext> (size = 319) = {...}, update=false) at kdevelop/plugins/clang/duchain/builder.cpp:1592
#63 0x00007f421b08301b in Builder::visit(CXTranslationUnitImpl*, void*, QHash<void*, KDevelop::ReferencedTopDUContext> const&, bool) (tu=0x7f41e015b5f0, file=0x7f41e1364bf0, includes=QHash<void *, KDevelop::ReferencedTopDUContext> (size = 319) = {...}, update=false) at kdevelop/plugins/clang/duchain/builder.cpp:1739
#64 0x00007f421b0f4895 in ClangHelpers::buildDUChain(void*, QMultiHash<void*, Import> const&, ParseSession const&, QFlags<KDevelop::TopDUContext::Feature>, QHash<void*, KDevelop::ReferencedTopDUContext>&, QHash<KDevelop::IndexedString, KDevelop::ModificationRevision> const&, KDevelop::IndexedString const&, ClangIndex*, std::function<bool ()> const&) (file=0x7f41e1364bf0, imports=QMultiHash<void *, Import> (size = 830) = {...}, session=..., features=..., includedFiles=QHash<void *, KDevelop::ReferencedTopDUContext> (size = 319) = {...}, unsavedRevisions=QHash<KDevelop::IndexedString, KDevelop::ModificationRevision> (size = 9) = {...}, parseDocument=..., index=0x561e582afda0, abortFunction=...) at kdevelop/plugins/clang/duchain/clanghelpers.cpp:209
#65 0x00007f421b4e82ce in ClangParseJob::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) (this=0x561e59a36890) at kdevelop/plugins/clang/clangparsejob.cpp:322
#66 0x00007f4287feb34c in ThreadWeaver::IdDecorator::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) () at /usr/lib/libKF5ThreadWeaver.so.5
#67 0x00007f4287feb12e in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () at /usr/lib/libKF5ThreadWeaver.so.5
#68 0x00007f4287fec076 in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () at /usr/lib/libKF5ThreadWeaver.so.5
#69 0x00007f4287fefdc2 in ThreadWeaver::Thread::run() () at /usr/lib/libKF5ThreadWeaver.so.5
#70 0x00007f4284ee432a in () at /usr/lib/libQt5Core.so.5
#71 0x00007f428489ebb5 in () at /usr/lib/libc.so.6
#72 0x00007f4284920d90 in () at /usr/lib/libc.so.6
Comment 31 Igor Kushnir 2023-03-07 17:15:27 UTC
*** Bug 466975 has been marked as a duplicate of this bug. ***
Comment 32 Igor Kushnir 2023-03-13 15:14:44 UTC
The bug fix just landed. It will be released in LLVM/Clang 17: https://github.com/llvm/llvm-project/commit/4d55a0b512a17dfaa2461b8803d37b79f6c9691d

Users affected by this bug can ask their distro maintainers to apply the fix to older LLVM packages. No need to apply the entire patch as it adds new API. The following reduced diff fixes the crash:

 int clang_getFieldDeclBitWidth(CXCursor C) {
   using namespace cxcursor;
 
   if (clang_isDeclaration(C.kind)) {
     const Decl *D = getCursorDecl(C);
 
-    if (const FieldDecl *FD = dyn_cast_or_null<FieldDecl>(D)) {
-      if (FD->isBitField())
-    if (const auto *FD = dyn_cast_or_null<FieldDecl>(D)) {
-      if (FD->isBitField() && !FD->getBitWidth()->isValueDependent())
         return FD->getBitWidthValue(getCursorContext(C));
     }
   }
Comment 33 Igor Kushnir 2023-03-16 06:33:33 UTC
https://github.com/llvm/llvm-project/commit/4d55a0b512a17dfaa2461b8803d37b79f6c9691d has been reverted and replaced with https://github.com/llvm/llvm-project/commit/48fb6659610a3177e8606681046dfa0d19f67203, which no longer adds new API, but instead shuffles declaration and adds documentation. The gist of the fix in clang/tools/libclang/CXType.cpp remains the same.
Comment 34 Igor Kushnir 2024-03-01 11:19:03 UTC
*** Bug 482109 has been marked as a duplicate of this bug. ***