| Summary: | KDevelop freezes when stopping project build | ||
|---|---|---|---|
| Product: | [Developer tools] kdevplatform | Reporter: | Valerio Pilo <valerio> |
| Component: | project | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | olivier.jg |
| Priority: | HI | ||
| Version: | 0.9.94 | ||
| Target Milestone: | 1.2.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
First time the freeze happened
Second time the freeze happened |
||
Created attachment 53364 [details]
Second time the freeze happened
This actually isn't related to the biuld job. Easy reproduction: Open or Reload KDevelop (or other largish project) Press stop Thread #1 hangs after importProjectJob.cpp:104 (d->m_watcher->waitForFinished();) That call to waitForFinished() happens after the requisite d->m_watcher->cancel(); Qt Docs for that cancel() function say: "Be aware that not all asynchronous computations can be canceled. For example, the future returned by QtConcurrent::run() cannot be canceled;" That watcher is indeed watching a QFuture that is started by QtConcurrent::run(). Presumably an import job, when created, should not be created with "setCapabilities(Killable)" (importProjectJob.cpp:66). This fixes it for me. Or perhaps it should be run in such a way that it can be safely canceled. Not sure which is preferable, so passing this on to whoever knows this code. Confirmed, and not a crash bug, but an easy to hit deadlock. More information on this: When you stop a project import, the main thread will wait for the project reload to finish. Unfortunately, in the case of a project import, there's often a bit of projectModel work being done, this involves signals being sent to the model using a BlockingQueuedConnection (in particular, this happens in ProjectBaseItem::setText). So, deadlock. Changing that to a QueuedConnection fixes that, but often CMakeManager will end up crashing with an assert instead (most probably unrelated to the QueuedConnection change, from what I can see). So, once again, why are ProjectImportJobs killable? Even when it works, the best you have is a useless half-open project. The fact that it doesn't work at all for at least two unrelated reasons means it should at least be disabled until it works, I think. if making it un-killable workarounds the bug please commit that hotfix. Git commit 30fb0611a497ed69ff90c9bee9c84f281223817b by Olivier JG. Committed on 04/07/2011 at 07:32. Pushed by olivierjg into branch 'master'. ProjectImportJob killing causes deadlocks/crashes. Until it works properly, don't make it killable. BUG: 256709 M +0 -2 project/importprojectjob.cpp http://commits.kde.org/kdevplatform/30fb0611a497ed69ff90c9bee9c84f281223817b |
Created attachment 53363 [details] First time the freeze happened Version: 4.1.0 (using KDE 4.5.3) OS: Linux Pressing Esc or clicking the Stop button while a CMake+Qt4 project is building makes KDev to freeze. The problem is reproducible with my project; I tried creating a new CMake+Qt4 project and restarting KDev, but with that project I couldn't make it to freeze. Reproducible: Always Steps to Reproduce: 1) Open a complex CMake+Qt4 project (mine has 3 targets each linking a common static library). 2) Remove/empty the builddir so it'll rebuild from scratch. 3) Start building the whole project. 4) Press Esc or activate the Stop All Processes QAction. Actual Results: KDevelop hangs. Expected Results: The build process gets stopped. I've reproduced the issue a number of times and debugged it in GDB. I'm attaching two backtraces. I cannot link you the project I'm getting the bug on (closed development for work) but I'm available on IRC to help you better pinpoint the issue. I'm vpilo on IRC@freenode.