|Summary:||KDevelop freezes when stopping project build|
|Product:||[Developer tools] kdevplatform||Reporter:||Valerio Pilo <valerio>|
|Latest Commit:||Version Fixed In:|
First time the freeze happened
Second time the freeze happened
Description Valerio Pilo 2010-11-12 15:54:17 UTC
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.
Comment 1 Valerio Pilo 2010-11-12 15:54:41 UTC
Created attachment 53364 [details] Second time the freeze happened
Comment 2 Olivier.jg 2010-12-16 08:39:43 UTC
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.
Comment 3 Olivier.jg 2010-12-16 08:43:19 UTC
Confirmed, and not a crash bug, but an easy to hit deadlock.
Comment 4 Milian Wolff 2010-12-16 17:03:13 UTC
Comment 5 Olivier.jg 2011-06-13 11:16:32 UTC
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.
Comment 6 Milian Wolff 2011-06-17 23:12:55 UTC
if making it un-killable workarounds the bug please commit that hotfix.
Comment 7 Olivier.jg 2011-07-04 05:44:09 UTC
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