| Summary: | Deadlock in DUChainLock::lockForWrite | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Chaos A.D. <chaos-ad> |
| Component: | Language Support: CPP (old) | Assignee: | kdevelop-bugs-null |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | aspotashev, faure |
| Priority: | NOR | ||
| Version First Reported In: | 4.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Chaos A.D.
2011-02-24 10:45:25 UTC
Reproducible: pretty easily :) Version: 4.2.60 how do you trigger this? by opening my cmake project with ~15 files, 2 of them with "using namespace blah::blah". is this project public, can we test it? I do not get this lockup for my projects. Nope, it's not, unfortunally. But I can try to reproduce it by experimenting with 'using namespace' in this project, and then, in case of success, strip it down to minimalistic testcase for you. I was hoping that the reason may be in some recent commits, and it will be obvious to find deadlock looking to callstack. sorry, won't reproduce :( Sorry but such a deadlock will need more information to be resolved properly I'm afraid. If you ever find a way to reproduce this issue please let me know. From the backtrace alone it more looks like a deadlock in DUChainLock::lockForWrite... I'll try to create a test for that and see whether I can reproduce anything... Git commit 36f9c05c650e48658c331df9a919b2d81132e7da by Milian Wolff. Committed on 09/01/2013 at 20:59. Pushed by mwolff into branch 'master'. Add three tests to check for deadlocks in the DUChainRead/Write locks. For me I cannot find any deadlock using this test, even though it continuously locks the duchain for read/write in multiple threads. M +99 -0 language/duchain/tests/test_duchain.cpp M +3 -0 language/duchain/tests/test_duchain.h http://commits.kde.org/kdevplatform/36f9c05c650e48658c331df9a919b2d81132e7da Got this deadlock today, due to ContextUsesWidget::linkWasActivated: it starts with DUChainReadLocker lock(DUChain::lock()); and keeps that locked when calling openDocument(), which (via many layers) ends up KDevelop::DUChain::documentLoadedPrepare, which creates a write locker. -> deadlock (or assertion first, in debug mode). Testcase: open kdepim, go to MessageList::Core::Model::setStorageModel, Show uses (of that method), click on the link to "View::setStorageModel" at the bottom. Boom. commit 15c8a3af8bec36ba73fc307eb1d4296949ab14d0 Author: David Faure <faure@kde.org> Date: Wed Mar 13 01:25:03 2013 +0100 Release the DUChain::lock() before calling openDocument We get an assert (debug) / deadlock (release) otherwise, in the case where a new view needs to be opened (KDevelop::DUChain::documentLoadedPrepare) CCBUG: 267042 (not closing, because the original bt is in IDebugSession::showStepInSource) kdevplatform/language/duchain/navigation/useswidget.cpp (and going through the OP's backtrace, I can't find an unreleased readlocker in these methods. But of course the code might have changed since then...) Moving all the bugs from the CPP Parser. It was not well defined the difference between it and C++ Language Support and people kept reporting in both places indistinctively |