Bug 466975

Summary:	kdevelop crashes when parsing wxWidgets source files
Product:	[Applications] kdevelop	Reporter:	nmset <nmset>
Component:	general	Assignee:	kdevelop-bugs-null
Status:	RESOLVED DUPLICATE
Severity:	crash	CC:	igorkuo, mail
Priority:	NOR	Keywords:	drkonqi
Version:	unspecified
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	New crash information added by DrKonqi

Description nmset 2023-03-06 21:13:54 UTC

Application: kdevelop (5.10.221203 (22.12.3))

Qt Version: 5.15.8
Frameworks Version: 5.103.0
Operating System: Linux 6.2.2-arch1-1 x86_64
Windowing System: X11
Distribution: "Arch Linux"
DrKonqi: 5.27.2 [KCrashBackend]

-- Information about the crash:
I am using kdevelop on Arch Linux to build wx apps as cmake projects. A few weeks or months ago, it was just fine. Now kdevelop 22.12.3 crashes when it parses the source files after the project is successfully loaded. Once in a while, it would load and parse successfully.

I can't know if it's related to kdevelop internals, or to a problem in the cmake files of wxWidgets. Other projects not involving wxWidgets do not have this issue. The problem has been tagged 'out of scope' on the wxWidgets forum.

The crash can be reproduced every time.

-- Backtrace (Reduced):
#6  __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:832
#7  0x00007fbc316aaae6 in llvm::APInt::APInt(llvm::APInt const&) () at /usr/include/llvm/ADT/APInt.h:157
#8  llvm::APSInt::APSInt(llvm::APSInt const&) () at /usr/include/llvm/ADT/APSInt.h:23
#10 0x00007fbc30866a43 in clang::FieldDecl::getBitWidthValue(clang::ASTContext const&) const () at /usr/src/debug/clang/clang-15.0.7.src/lib/AST/Decl.cpp:4283
#11 0x00007fbc9037bbef in (anonymous namespace)::Visitor::setDeclData<(CXCursorKind)1>(CXCursor, KDevelop::ClassMemberDeclaration*) const [clone .isra.0] (cursor=..., decl=decl@entry=0x7fbc369a0110, this=<optimized out>) at /usr/src/debug/kdevelop/kdevelop-22.12.3/plugins/clang/duchain/builder.cpp:1157


Reported using DrKonqi

Comment 1 nmset 2023-03-06 21:13:55 UTC

Created attachment 157068 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.

Comment 2 nmset 2023-03-06 21:27:20 UTC

This workaround no longer works :

https://bugs.kde.org/show_bug.cgi?id=438249#c4

Comment 3 Igor Kushnir 2023-03-07 09:21:59 UTC

(In reply to nmset from comment #2)
> This workaround no longer works :
> 
> https://bugs.kde.org/show_bug.cgi?id=438249#c4
In my version of KDevelop (master), plugins/clang/duchain/builder.cpp:1157 points to the line `decl->setBitWidth(clang_getFieldDeclBitWidth(cursor));`. If the line of code is the same in your version, then the workaround *must* work and this is a duplicate of Bug 438249. The fix is being actively reviewed here: https://reviews.llvm.org/D130303. So there is a good chance the bug will be gone in LLVM/Clang version 17.

Comment 4 nmset 2023-03-07 16:47:49 UTC

(In reply to Igor Kushnir from comment #3)

> the workaround *must*
> work 

Self-built kdevelop with 'decl->setBitWidth(-1)' does not crash while loading a wxWidgets project if :
 - the built binaries are packaged using Arch's utility (makepkg),
 - the package is installed system wide using Arch's package manager (pacman).
 
Self-built kdevelop with 'decl->setBitWidth(-1)' still crashes if :
 - it is run inside the build tree (./bin/kdevelop),
 - Arch's stock kdevelop package is installed system wide (without which, kdevcmakemanager is reported missing when a project is loaded from the menu, which is on top of an empty window).
 
So the patch is efficient. I can do this way until the fix is generally available.

Thank you for your reply.

Comment 5 Sven Brauch 2023-03-07 17:02:15 UTC

Yeah, because your self-built KDevelop will load the system one's plugins. You can fix that by uninstalling the system version and setting the QT_PLUGIN_PATH environment variable to your local installation's .../qt/plugins/ folder.

Comment 6 Igor Kushnir 2023-03-07 17:15:27 UTC

*** This bug has been marked as a duplicate of bug 438249 ***