I'm getting this crash very frequently, but still it's hard to reproduce. This always happens when opening a certain file, and the only way to fix the problem is to delete the duchain cache. It's hard to reproduce, but my impression is, that during re-parsing, some problems and/or diagnostics are not updated properly, so that they reference the wrong problem indices as children, thus producing a recursive linkage. It may be due to the weird things that happen in LocalIndexedProblem::LocalIndexedProblem. The ideal solution would be to avoid the duplicity of the "m_diagnostics" member in KDevelop::Problem and its duchain version in ProblemData. Why not just store the child diagnostics in DUChainData as IndexProblem' And deserialize the diagnostics on-demand? Here's the backtrace: #2628 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5ceaa30, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2629 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f1fc00, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2630 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5ea9c00, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2631 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5c64a90, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2632 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f1d2c0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2633 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5e8b9b0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2634 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5d6c510, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2635 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f1a560, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2636 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5e87e90, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2637 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f19900, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2638 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f4a5e0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2639 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5e84790, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2640 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f16fc0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2641 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5e832f0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2642 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5e802d0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2643 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f14260, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2644 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5e7e750, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2645 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f13600, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2646 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5aa4fe0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2647 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5deb130, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2648 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5f11500, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 #2649 0x00007ffff7af2085 in (anonymous namespace)::addDiagnostics (node=0x5e7aad0, diagnostics=...) at /home/nolden/kdedev/source/extragear/kdevelop/kdevplatform/shell/filteredproblemstore.cpp:40 Reproducible: Always
Note that I'm currently testing a patch to fix this. Until now it seems to work. I'll commit it if the bug doesn't reappear. The trick is to always re-index the child diagnostics in LocalIndexedProblem::LocalIndexedProblem(...), to ensure that the indices are current. At the moment there is some logic which avoids the re-indexing if the number of diagnostics didn't change, which is probably wrong, because the diagnostics themselves may have changed, even if their count didn't change.
Please post to Phabricator if it's a non-trivial patch. I've never seen that issue, fwiw.
Git commit 5abba92236eca24126a6863f1eec149693a9c4f9 by David Nolden. Committed on 04/07/2016 at 12:12. Pushed by zwabel into branch '5.0'. Fix possible crash in ProblemStore::addDiagnostic The problem was, that child problem indices weren't updated when the number of child problems didn't change. When that happened, then child problem indices could be wrong and basically random, thus creating a recursive link which would normally be impossible. The solution is, to always re-index the children when storing the problem, no matter whether the child count changed or not. M +6 -9 language/duchain/problem.cpp http://commits.kde.org/kdevplatform/5abba92236eca24126a6863f1eec149693a9c4f9
The patch was actually quite trivial, the conditional "if (static_cast<uint>(problem->m_diagnostics.size()) != problem->d_func()->diagnosticsSize())" simply needed to be removed so that indices are updated.