Created attachment 53363 [details]
First time the freeze happened
Version: 4.1.0 (using KDE 4.5.3)
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.
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.
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.
Open or Reload KDevelop (or other largish project)
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.
M +0 -2 project/importprojectjob.cpp