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

[Sven Brauch]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128829/
-----------------------------------------------------------

Review request for KDevelop.


Repository: kdevelop


Description
-------

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 https://git.reviewboard.kde.org/r/128830/ or it will just assert out.


Diffs
-----

  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 

Diff: https://git.reviewboard.kde.org/r/128829/diff/


Testing
-------

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.


Thanks,

Sven Brauch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160904/f274db24/attachment.html>