Turn off branch change detection as it leads to endless loop and CPU leak

Aleksey Midenkov midenok at gmail.com
Thu Dec 26 18:39:57 GMT 2019


On Thu, Dec 26, 2019 at 9:06 PM Aleksey Midenkov <midenok at gmail.com> wrote:

>
>
> On Wed, Dec 25, 2019 at 3:49 PM René J.V. Bertin <rjvbertin at gmail.com>
> wrote:
>
>> On Wednesday December 25 2019 14:09:16 Aleksey Midenkov wrote:
>>
>> >change which happen quite frequently. So please, add an ability to turn
>> off
>> >branch change detection.
>>
>> Does this also happen when you change branches that do not have any
>> differences between them, i.e. when no files are being checked out? Does it
>> make a difference if you have the project configured to be parsed
>> completely on open or not?
>
>
> I don't know where it is configured. I use Custom Build System. Where is
> this option?
>
>
>> Do you use precompiled headers?
>
>
> Is it an option of KDevelop and where is it?
>
> Actually syntax parser is broken in several ways. Now it red-underlined
> lots of types in files (almost all or all of them) as syntax errors. I
> tried to jump from one of them and it jumped to the beginning of some
> random unrelated file and after that everything was fixed. All red "errors"
> was gone.
>

I managed to reproduce this one again and attached some screenshots. This
happens also on branch change. This particular branch change updates not
much files, but it updates files that are currently opened and one of them
is edited in KDevelop. No, I don't know what happens when `git branch`
doesn't update anything. I believe KDevelop won't fail in that case. I
noticed the failures only on file updates and the more branch is different
the more chances KDevelop will fail.

I attached 3 screenshots. One of them is non-jumpable type and its error,
other one is jumpable type which jump fixed the fail last time but it
doesn't fix the fail this time. And one of them where KDevelop jumps from
this jumpable type.

I believe you don't test your software properly, do you?
>
>
>>
>> If what you describe comes in fact from reaction to bulk file changes
>> then there isn't much that can be done. You could add a feature to ignore
>> file changes for a predefined period or until further notice, but that too
>> will lead to incorrect parsing information for those files that did indeed
>> change.
>>
>> R.
>>
>
>
> --
> All the best,
>
> Aleksey Midenkov
> @midenok
>


-- 
All the best,

Aleksey Midenkov
@midenok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20191226/f497407d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: non-jumpable.jpeg
Type: image/jpeg
Size: 312057 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20191226/f497407d/attachment-0003.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jumpable.jpeg
Type: image/jpeg
Size: 322617 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20191226/f497407d/attachment-0004.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jump_target.jpeg
Type: image/jpeg
Size: 298250 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20191226/f497407d/attachment-0005.jpeg>


More information about the KDevelop mailing list