Bug 358311 - broken highlighting
Summary: broken highlighting
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (Clang-based) (show other bugs)
Version: git master
Platform: Other Linux
: VHI major
Target Milestone: 5.0.0
Assignee: kdevelop-bugs-null
URL:
Keywords: release_blocker
Depends on:
Blocks:
 
Reported: 2016-01-21 13:41 UTC by Milian Wolff
Modified: 2016-07-25 06:41 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0
Sentry Crash Report:


Attachments
broken highlighting (105.51 KB, image/png)
2016-01-21 13:43 UTC, Milian Wolff
Details

Note You need to log in before you can comment on or make changes to this bug.
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.