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.
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.
see also: http://lists.kde.org/?l=kdevelop-devel&m=129027254932711&w=2
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