Summary: | KDevelop C++ parser crash [DeclarationBuilder::closeDeclaration] | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | RJVB <rjvbertin> |
Component: | Language Support: CPP (old) | Assignee: | kdevelop-bugs-null |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | christof.hanke, eduard_kalinowski, gnux83, kfunk, Kicer86, rjvbertin |
Priority: | NOR | Keywords: | drkonqi |
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | macOS | ||
Latest Commit: | http://commits.kde.org/kdevelop/f78c39655cb3d5dacca43fde60c7e748efb10820 | Version Fixed In: | 4.7.3 |
Sentry Crash Report: | |||
Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi |
Description
RJVB
2015-11-21 11:12:55 UTC
What line did it crash in? frame #4: 0x0000000128a54598 libkdev4cppduchain.dylib`DeclarationBuilder::closeDeclaration(bool) + 1800 what is this supposed to mean? Can you translate that to an easier-to-understand GDB-like backtrace with file:line information? Also, it may quite likely be closed as wontfix anyway as we are spending our time on kdev-clang nowadays. If it's an easy fix we may want to fix it for 4.7 though. I'm afraid gdb hasn't worked properly on OS X for years now (didn't you know that?), but if I remember (and find a moment) to rebuild kdevelop without LTO I should get line numbers. I thought the "__list_imp< _Tp, _Alloc >" "__list_imp< _Tp, _Alloc >" output came from an ASSERT or something like that, but you're right, I see neither "abort" nor "qFatal" in the backtrace. I can confirm this bug which is a total stopper for me. Here is the top of the stack: #0 0x0000000000000000 in ?? () #1 0x00007fff3dc1fdc1 in DeclarationBuilder::closeDeclaration (this=0x7fff35ff3560, forceInstance=<optimized out>) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/declarationbuilder.cpp:866 #2 0x00007fff3dc1f429 in DeclarationBuilder::visitDeclarator (this=0x7fff35ff3560, node=0x7fff15e11968) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/declarationbuilder.cpp:475 #3 0x00007fff3dc0e5f7 in ContextBuilder::visitInitDeclarator (this=this@entry=0x7fff35ff3560, node=node@entry=0x7fff15e120d0) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/contextbuilder.cpp:911 #4 0x00007fff3dc1d9c6 in DeclarationBuilder::visitInitDeclarator (this=0x7fff35ff3560, node=0x7fff15e120d0) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/declarationbuilder.cpp:255 #5 0x00007fff3dc3b03d in TypeBuilder::visitSimpleDeclaration (this=this@entry=0x7fff35ff3560, node=node@entry=0x7fff15e12110) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/typebuilder.cpp:690 #6 0x00007fff3dc1d104 in DeclarationBuilder::visitSimpleDeclaration (this=0x7fff35ff3560, node=0x7fff15e12110) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/declarationbuilder.cpp:349 #7 0x00007fff3d96130d in visitNodes<DeclarationAST*> (v=v@entry=0x7fff35ff35b8, nodes=<optimized out>) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/parser/visitor.h:139 #8 0x00007fff3d960a52 in DefaultVisitor::visitClassSpecifier (this=this@entry=0x7fff35ff35b8, node=node@entry=0x7fff15e90308) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/parser/default_visitor.cpp:68 #9 0x00007fff3dc0d3af in ContextBuilder::visitClassSpecifier (this=this@entry=0x7fff35ff3560, node=node@entry=0x7fff15e90308) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/contextbuilder.cpp:534 #10 0x00007fff3dc3c2a2 in TypeBuilder::visitClassSpecifier (this=this@entry=0x7fff35ff3560, node=node@entry=0x7fff15e90308) at /home/michal/projects/sources/external/kdevelop-4.7.2/languages/cpp/cppduchain/typebuilder.cpp:92 That certainly looks like the same crash to me. For me, this crash only happens when KDevelop is parsing a bunch of projects after opening a session (and apparently preferably when the session contains many projects). I don't think it ever happened when the parser reparsed an open file after modification. If it's impossible to resolve the underlying issue, a workaround could then be to 1) defer parsing to after all projects are loaded completely 2) make the automatic start of the parser optional, and provide a way (button, menu action) to trigger the parsing of an entire project manually. Option 1) would be probably less sure as a workaround. Option 2) can currently be approximated by deactivating the parser altogether, then you lose all benefits of code parsing -- AFAIK deactivation will also discard all cached parsing information. I also still don't understand why it is necessary to parse a file when it hasn't changed since the last parsing step. Why not simply load the cached information, and only trigger the parser when the file changes (either in the embedded editor or when a timestamp and/or hash/CRC mismatch is detected)? Created attachment 95775 [details]
New crash information added by DrKonqi
kdevelop (4.7.2) on KDE Platform 4.14.14 using Qt 4.8.7
- What I was doing when the application crashed:
Same story: crash after opening a session with multiple project, during the initial (re)parse that cannot be avoided if you want to benefit from parsing information at all.
Last couple of lines on the terminal:
kdevelop(67561)/kdevplatform (language) KDevelop::TopDUContextDynamicData::DUChainItemStorage<KDevelop::Declaration *>::getItemForIndex: invalid item for index 1715 2743 0
kdevelop(67561)/kdevplatform (language) KDevelop::TopDUContextDynamicData::DUChainItemStorage<KDevelop::Declaration *>::getItemForIndex: invalid item for index 3408 2743 0
kdevelop(67561)/kdevplatform (language) KDevelop::TopDUContextDynamicData::DUChainItemStorage<KDevelop::Declaration *>::getItemForIndex: invalid item for index 2538 2743 0
kdevelop(67561)/kdevplatform (language) KDevelop::TopDUContextDynamicData::DUChainItemStorage<KDevelop::Declaration *>::getItemForIndex: invalid item for index 1717 2743 0
kdevelop(67561)/kdevplatform (language) KDevelop::TopDUContextDynamicData::DUChainItemStorage<KDevelop::Declaration *>::getItemForIndex: invalid item for index 3410 2743 0
kdevelop(67561)/kdevplatform (language) KDevelop::TopDUContextDynamicData::DUChainItemStorage<KDevelop::Declaration *>::getItemForIndex: invalid item for index 2540 2743 0
kdevelop(67561)/kdevplatform (language) KDevelop::TopDUContextDynamicData::DUChainItemStorage<KDevelop::Declaration *>::getItemForIndex: invalid item for index 1719 2743 0
kdevelop(67561)/kdevelop (cpp support) *Cpp::instantiateDeclarationAndContext: Resolved bad base-class "__list_imp< _Tp, _Alloc >" "__list_imp< _Tp, _Alloc >"
KCrash: Application 'kdevelop' crashing...
KCrash: Attempting to start /opt/local/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi directly
According to the progress indicator, kdelibs4support/src/kdecore/ksystemtimezone.h (from git/head) was being parsed.
-- Backtrace (Reduced):
@Michal: Which project is this? Is the crash always reproducible? Confirming b/c of multiple reports. @Kevin: I used to have it every time, but now it's more random. But as far as I can see it is reproducible every time I remove ~/.cache/kdevduchain Here's the project: https://github.com/Kicer86/photobroom For the record: Can't reproduce on Linux. @Kevin: If you want I can compile kdevelop with some patch or extra options If you need more information. Do you remove the cache while kdevelop is running? No, not I, at least not that I know of ... @Milian Wolff: I did it before starting KDevelop. My KDevelop was crashing every time, but then it somehow dealt with the problem and was not crashing anymore (I guess cache had all the data so there was no need to parse all files again). To reproduce the problem again I had to remove cache. Well, without a way for me to reproduce this, I'm tempted to close this as UNMAINTAINED, as it only affects our old C++ parser. With kdev-clang / KDevelop 5, this issue should not occur anymore... *** Bug 353863 has been marked as a duplicate of this bug. *** *** Bug 357358 has been marked as a duplicate of this bug. *** Git commit f78c39655cb3d5dacca43fde60c7e748efb10820 by Milian Wolff. Committed on 21/01/2016 at 12:41. Pushed by mwolff into branch '4.7'. Don't access declaration without holding the DUChain lock. This hopefully fixes a crash in the declaration builder. M +9 -6 languages/cpp/cppduchain/declarationbuilder.cpp http://commits.kde.org/kdevelop/f78c39655cb3d5dacca43fde60c7e748efb10820 Created attachment 99091 [details]
New crash information added by DrKonqi
kdevelop (4.7.3) on KDE Platform 4.14.16 using Qt 4.8.7
Loading session with many open projects and files, KDevelop crashes when clicked F8 (build) before session is loaded completly and first background parse is finished.
-- Backtrace (Reduced):
#7 0x00007f2a2d3e4710 in DeclarationBuilder::closeDeclaration (this=0x7f2a2143c630, forceInstance=<optimized out>) at /build/kdevelop-jGcNEc/kdevelop-4.7.3/languages/cpp/cppduchain/declarationbuilder.cpp:865
#8 0x00007f2a2d3e606b in DeclarationBuilder::visitDeclarator (this=0x7f2a2143c630, node=0x7f29f44d8d38) at /build/kdevelop-jGcNEc/kdevelop-4.7.3/languages/cpp/cppduchain/declarationbuilder.cpp:475
#9 0x00007f2a2d3d599f in ContextBuilder::visitInitDeclarator (this=this@entry=0x7f2a2143c630, node=node@entry=0x7f29f44d94a0) at /build/kdevelop-jGcNEc/kdevelop-4.7.3/languages/cpp/cppduchain/contextbuilder.cpp:911
#10 0x00007f2a2d3e167c in DeclarationBuilder::visitInitDeclarator (this=0x7f2a2143c630, node=0x7f29f44d94a0) at /build/kdevelop-jGcNEc/kdevelop-4.7.3/languages/cpp/cppduchain/declarationbuilder.cpp:255
#11 0x00007f2a2d40289c in TypeBuilder::visitSimpleDeclaration (this=this@entry=0x7f2a2143c630, node=node@entry=0x7f29f44d94e0) at /build/kdevelop-jGcNEc/kdevelop-4.7.3/languages/cpp/cppduchain/typebuilder.cpp:690
@gnux83: Reproducible everytime? Please post the full backtrace in this case. *** Bug 362413 has been marked as a duplicate of this bug. *** |