Bug 488043 - KDevelop crashed when loading a KDevGenericManager project
Summary: KDevelop crashed when loading a KDevGenericManager project
Status: CONFIRMED
Alias: None
Product: kdevelop
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: OpenMandriva Linux
: NOR crash
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords: drkonqi
: 470428 511678 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-06-05 01:03 UTC by Davide Beatrici
Modified: 2025-11-28 08:45 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
New crash information added by DrKonqi (194.61 KB, text/plain)
2024-06-05 01:03 UTC, Davide Beatrici
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Davide Beatrici 2024-06-05 01:03:47 UTC
Application: kdevelop (5.14.240500 (24.05.0))

Qt Version: 6.7.1
Frameworks Version: 6.2.0
Operating System: Linux 6.9.1-desktop-1omv2490 x86_64
Windowing System: X11
Distribution: "OpenMandriva Lx 24.06"
DrKonqi: 6.0.5 [CoredumpBackend]

-- Information about the crash:
The crash happened almost immediately. Upon restarting the program, I chose to delete the cache and then I opened the project again, which was loaded just fine.

The crash can be reproduced sometimes.

-- Backtrace (Reduced):
#5  0x00007fbd5c8e7476 in std::__fill_a1<unsigned short*, int> (__first=0x7fbd1690d33e, __last=0x7fbd1690ecd8, __value=<optimized out>) at /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/14.1.0/../../../../include/c++/14.1.0/bits/stl_algobase.h:952
#6  std::__fill_a<unsigned short*, int> (__first=0x7fbd1690d33e, __last=0x7fbd1690ecd8, __value=<optimized out>) at /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/14.1.0/../../../../include/c++/14.1.0/bits/stl_algobase.h:998
#7  std::__fill_n_a<unsigned short*, int, int> (__first=0x7fbd1690d33e, __n=3277, __value=<optimized out>) at /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/14.1.0/../../../../include/c++/14.1.0/bits/stl_algobase.h:1151
#8  std::fill_n<unsigned short*, KDevelop::Bucket<KDevelop::CodeModelRepositoryItem, KDevelop::CodeModelRequestItem, true, 0u>::{unnamed type#3}, int>(KDevelop::Bucket<KDevelop::CodeModelRepositoryItem, KDevelop::CodeModelRequestItem, true, 0u>::{unnamed type#3}, KDevelop::Bucket<KDevelop::CodeModelRepositoryItem, KDevelop::CodeModelRequestItem, true, 0u>::{unnamed type#3}, int const&) (__first=0x7fbd1690d33e, __n=KDevelop::Bucket<KDevelop::CodeModelRepositoryItem, KDevelop::CodeModelRequestItem, true, 0u>::NextBucketHashSize, __value=<optimized out>) at /usr/bin/../lib64/gcc/x86_64-openmandriva-linux-gnu/14.1.0/../../../../include/c++/14.1.0/bits/stl_algobase.h:1180
#9  KDevelop::Bucket<KDevelop::CodeModelRepositoryItem, KDevelop::CodeModelRequestItem, true, 0u>::takeNextBucketHash (this=0x7fbbcc1d0560) at /usr/src/debug/kdevelop-24.05.0-1.x86_64/kdevplatform/serialization/itemrepository.h:734


Reported using DrKonqi
Comment 1 Davide Beatrici 2024-06-05 01:03:48 UTC
Created attachment 170153 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.
Comment 2 Igor Kushnir 2024-06-05 08:09:51 UTC
(In reply to Davide Beatrici from comment #0)
> The crash happened almost immediately. Upon restarting the program, I chose
> to delete the cache and then I opened the project again, which was loaded just fine.
Did you update Clang just before the crash occurred? Perhaps the cache is incompatible between [major] libclang versions.
Comment 3 Davide Beatrici 2024-06-05 23:36:50 UTC
Just checked: no updates to the Clang packages and it was the first time I opened the project after a fresh system reinstall (I didn't transfer ~/.cache over).
Comment 4 Igor Kushnir 2024-06-06 12:34:02 UTC
(In reply to Davide Beatrici from comment #3)
> Just checked: no updates to the Clang packages and it was the first time I
> opened the project after a fresh system reinstall (I didn't transfer
> ~/.cache over).
Then it's probably a bug in CodeModel or ItemRepository somewhere. The backtrace looks good and may be used to find and fix a bug. If only someone had the time for that...
Comment 5 Igor Kushnir 2025-11-05 18:38:45 UTC
*** Bug 511678 has been marked as a duplicate of this bug. ***
Comment 6 Igor Kushnir 2025-11-05 18:51:41 UTC
*** Bug 470428 has been marked as a duplicate of this bug. ***
Comment 7 Igor Kushnir 2025-11-05 18:53:08 UTC
There are about 10 core dumps with `takeNextBucketHash()` in my crash collection. But they all happen in the PersistentSymbolTable rather than in the CodeModel item repository. Restarting KDevelop without clearing the cache results in the same crash. Clearing the cache usually allows the parsing to complete successfully. The most recent such crash occurred in April this year. The reduced backtrace of this last crash of mine:
Thread 1 (Thread 0x7fc230a916c0 (LWP 64212)):
[KCrash Handler]
#4  0x00007fc2cdc0e9ef in std::__fill_a1<unsigned short*, int> (__first=0x7fc25e0cd654, __last=0x7fc25e0cefee, __value=<optimized out>, __first=<optimized out>, __last=<optimized out>, __value=<optimized out>) at /usr/include/c++/14.2.1/bits/stl_algobase.h:952
#5  std::__fill_a<unsigned short*, int> (__first=0x7fc25e0cd654, __last=0x7fc25e0cefee, __value=<optimized out>, __first=<optimized out>, __last=<optimized out>, __value=<optimized out>) at /usr/include/c++/14.2.1/bits/stl_algobase.h:998
#6  std::__fill_n_a<unsigned short*, int, int> (__first=0x7fc25e0cd654, __n=3277, __value=<optimized out>, __first=<optimized out>, __n=<optimized out>, __value=<optimized out>) at /usr/include/c++/14.2.1/bits/stl_algobase.h:1154
#7  std::fill_n<short unsigned int*, KDevelop::Bucket<KDevelop::(anonymous namespace)::PersistentSymbolTableItem, KDevelop::(anonymous namespace)::PersistentSymbolTableRequestItem, true, 0>::<unnamed enum>, int> (__first=0x7fc25e0cd654, __n=KDevelop::Bucket<KDevelop::(anonymous namespace)::PersistentSymbolTableItem, KDevelop::(anonymous namespace)::PersistentSymbolTableRequestItem, true, 0>::NextBucketHashSize, __value=<optimized out>) at /usr/include/c++/14.2.1/bits/stl_algobase.h:1183
#8  KDevelop::Bucket<KDevelop::(anonymous namespace)::PersistentSymbolTableItem, KDevelop::(anonymous namespace)::PersistentSymbolTableRequestItem, true, 0>::takeNextBucketHash (this=0x7fc219275b70) at kdevelop/kdevplatform/serialization/itemrepository.h:734
#9  KDevelop::ItemRepository<KDevelop::(anonymous namespace)::PersistentSymbolTableItem, KDevelop::(anonymous namespace)::PersistentSymbolTableRequestItem, true, QRecursiveMutex, 0u, 1048576u>::convertMonsterBucket(int, int) [clone .isra.0] (this=0x7fc2cf06d140 <_ZZN8KDevelop17ItemRepositoryForINS_21PersistentSymbolTableEE4repoEvE4repo.lto_priv.0>, bucketNumber=<optimized out>, extent=1) at kdevelop/kdevplatform/serialization/itemrepository.h:2144
#10 0x00007fc2cdc0eff4 in KDevelop::ItemRepository<KDevelop::(anonymous namespace)::PersistentSymbolTableItem, KDevelop::(anonymous namespace)::PersistentSymbolTableRequestItem, true, QRecursiveMutex, 0u, 1048576u>::index(KDevelop::(anonymous namespace)::PersistentSymbolTableRequestItem const&) [clone .isra.0] (this=<optimized out>, request=...) at kdevelop/kdevplatform/serialization/itemrepository.h:1396
#11 0x00007fc2cdb334be in operator() (__closure=<optimized out>, repo=...) at kdevelop/kdevplatform/language/duchain/persistentsymboltable.cpp:325
#12 KDevelop::LockedItemRepository::write<KDevelop::PersistentSymbolTable, KDevelop::PersistentSymbolTable::addDeclaration(const KDevelop::IndexedQualifiedIdentifier&, const KDevelop::IndexedDeclaration&)::<lambda(KDevelop::(anonymous namespace)::PersistentSymbolTableRepo&)> > (op=<optimized out>) at kdevelop/kdevplatform/serialization/itemrepository.h:2552
#13 KDevelop::PersistentSymbolTable::addDeclaration (this=<optimized out>, id=<optimized out>, declaration=<optimized out>) at kdevelop/kdevplatform/language/duchain/persistentsymboltable.cpp:285
#14 0x00007fc2cdaf2d4f in KDevelop::Declaration::setInSymbolTable (this=0x7fc2192629e0, inSymbolTable=<optimized out>) at kdevelop/kdevplatform/language/duchain/declaration.cpp:620
#15 0x00007fc25c2a5f6d in (anonymous namespace)::Visitor::createDeclarationCommon<(CXCursorKind)1, KDevelop::Declaration> (this=0x7fc230a8f660, cursor=..., id=...) at kdevelop/plugins/clang/duchain/builder.cpp:448
#16 0x00007fc25c2a2fc3 in (anonymous namespace)::Visitor::createDeclaration<(CXCursorKind)1, KDevelop::Declaration> (context=0x0, this=0x7fc230a8f660, cursor=..., id=...) at kdevelop/plugins/clang/duchain/builder.cpp:454
#17 (anonymous namespace)::Visitor::buildDeclaration<(CXCursorKind)1, KDevelop::Declaration, false> (this=0x7fc230a8f660, cursor=...) at kdevelop/plugins/clang/duchain/builder.cpp:1296
#18 (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)1, (Decision)1, (Decision)1> (this=0x7fc230a8f660, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:1007
#19 (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)1> (this=0x7fc230a8f660, cursor=..., parent=...) at kdevelop/plugins/clang/duchain/builder.cpp:971
#20 (anonymous namespace)::visitCursor (cursor=..., parent=..., data=0x7fc230a8f660) at kdevelop/plugins/clang/duchain/builder.cpp:1675
#21 0x00007fc24c474b8c in ??? () at /usr/lib/libclang.so.19.1
#22 0x00007fc24c476a12 in ??? () at /usr/lib/libclang.so.19.1
#23 0x00007fc24c476d70 in ??? () at /usr/lib/libclang.so.19.1
#24 0x00007fc24c473cde in ??? () at /usr/lib/libclang.so.19.1
#25 0x00007fc24c4777ad in clang_visitChildren () at /usr/lib/libclang.so.19.1
#26 0x00007fc25c29e7c1 in (anonymous namespace)::Visitor::Visitor (this=0x7fc230a8f660, tu=<optimized out>, file=<optimized out>, includes=<optimized out>, update=<optimized out>) at kdevelop/plugins/clang/duchain/builder.cpp:1595
#27 Builder::visit (tu=<optimized out>, file=<optimized out>, includes=<optimized out>, update=<optimized out>) at kdevelop/plugins/clang/duchain/builder.cpp:1744
#28 0x00007fc25c2b5799 in ClangHelpers::buildDUChain (file=<optimized out>, imports=<optimized out>, session=..., features=..., includedFiles=..., unsavedRevisions=..., parseDocument=..., index=0x55b4e1871cb0, abortFunction=...) at kdevelop/plugins/clang/duchain/clanghelpers.cpp:209
#29 0x00007fc25c2b50eb in ClangHelpers::buildDUChain (file=<optimized out>, imports=..., session=..., features=..., features@entry=..., includedFiles=..., unsavedRevisions=..., parseDocument=..., index=0x55b4e1871cb0, abortFunction=...) at kdevelop/plugins/clang/duchain/clanghelpers.cpp:121
#30 0x00007fc25c367fba in ClangParseJob::run (this=0x55b4ea25ba30) at kdevelop/plugins/clang/clangparsejob.cpp:323
Comment 8 Igor Kushnir 2025-11-05 18:59:12 UTC
The similar PersistentSymbolTable crash is tracked in Bug 480526.
Comment 9 Igor Kushnir 2025-11-28 08:45:37 UTC
https://commits.kde.org/kdevelop/9505bcf950fd3917f4d9f9bf662bf87fa63f4482 will be released in KDevelop 6.4.251200 and may fix this bug.