Review Request 128829: [1/2] clang parse job: do initialization in run(), not in the constructor

Sven Brauch mail at
Sun Sep 4 15:37:25 UTC 2016

This is an automatically generated e-mail. To reply, visit:

Review request for KDevelop.

Repository: kdevelop


The constructor of the parse job is called from createParseJob(), which
is called from the background parser with the background parser mutex
locked. If the constructor acquires a DUChain lock (which it did), then
any thread which acquires the DUChain lock first and then the background
parser mutex will cause a deadlock. Other language plugins do this a lot,
esp. qmljs and to some extent also python, by calling
BackgroundParser::isQueued() with the DUChain lock held.

By doing the initialization in run() with the ForegroundLock held,
we avoid this problem.

This is a severe bug, I hit it quite often and I have read more than one
report from users complaining about freezing as well.

Requires or it will just assert out.


  languages/clang/clangparsejob.h 7c0ab7a 
  languages/clang/clangparsejob.cpp d676aea 
  languages/plugins/custom-definesandincludes/compilerprovider/settingsmanager.cpp 590ba4a 
  languages/plugins/custom-definesandincludes/definesandincludesmanager.cpp df1be68 



Opened several large sessions in a debug build, didn't see any more freezes during initial parsing. Before this was really easy to observe if you opened a C++ and a JS project in parallel.


Sven Brauch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list