Bug 358311

Summary: broken highlighting
Product: [Applications] kdevelop Reporter: Milian Wolff <mail>
Component: Language Support: CPP (Clang-based)Assignee: kdevelop-bugs-null
Status: RESOLVED FIXED    
Severity: major CC: alexander, mail
Priority: VHI Keywords: release_blocker
Version First Reported In: git master   
Target Milestone: 5.0.0   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In: 5.0.0
Sentry Crash Report:
Attachments: broken highlighting

Description Milian Wolff 2016-01-21 13:41:58 UTC 
Sometimes the highlighting of files is severely broken as shown in the attached screenshot.

This may be related to:

- missing translations of DUChain cursor/range locations
- improper revision locking
- delay between reading content from editor and actually parsing it

This may be triggered by:

- pasting content
- switching branches

In general, hard to reproduce, but when it hits you, you'll notice. F5 is the only rescue in such situations.

Reproducible: Sometimes
Comment 1 Milian Wolff 2016-01-21 13:43:09 UTC 
Created attachment 96766 [details]
broken highlighting
Comment 2 Milian Wolff 2016-01-30 16:20:14 UTC 
Personally, I haven't seen this issue anymore since introducing DUChain::updateReady and leveraging that in kdev-clang. I.e. Since Jan 23. Can anybody confirm? Or is this still an issue?
Comment 3 Milian Wolff 2016-02-03 15:31:43 UTC 
Still valid, I just reproduced it again.
Comment 4 Alexander Zhigalin 2016-04-15 00:16:05 UTC 
Also broken in php and less files
Comment 5 Milian Wolff 2016-07-10 22:12:00 UTC 
Alexander, you have seen this breaking in PHP files? Can you show a screenshot please? If that is not - as I thought - a bug in kdev-clang then it would allow us to search for the culprit in the libs somewhere... Such feedback would be very welcome.
Comment 6 Sven Brauch 2016-07-16 11:45:27 UTC 
It _occasionally_ happens in other languages as well, but you need quite strange conditions to trigger that. I think the git auto-reload is a good starting point there.

In clang the issue is different though, I'm certain. It somehow does not lock the correct modification revision, or doesn't do so at the right time, and if you insert a newline at exactly the right moment during the parsing run, this issue triggers. That doesn't happen in e.g. Python.
Comment 7 Sven Brauch 2016-07-16 15:18:12 UTC 
To be more correct, I have not _seen_ this happening in other languages. It is some kind of race condition; it is possible it exists in the other languages as well, but only triggers that often for clang because its parse job spends more time in a certain section.
Comment 9 Sven Brauch 2016-07-22 14:11:10 UTC 
Should be fixed, it not, please reopen.