When browsing or editing python 2.x code, Kdevelop randomly hangs, or is unresponsive. Reproducible: Sometimes Steps to Reproduce: Don't know. But it keeps happening. Actual Results: "Hang" Will attach gdb backtrace
Created attachment 95408 [details] Output of gdb "thread apply all bt"
First, please try to clear the code cache (rm -Rf ~/.cache/kdevduchain). Is the problem still reproducable? If yes, it looks like it hangs when trying to display some type, eventually in a popup or so. Can you tell me which code you're looking at when this happens?
I see the same issue on a "C" file. Entering the line "bool x = true;", and hovering over "true" will hang KDevelop, at 100% of CPU core. I don't know if the size of the project is important, but this is a large project where the literal "true" is used many places. Attaching "thread apply all bt" below. Kdevelop 4.7.2, on KDE 4.14.11 from Fedora 21 packages. This is a new regression, updated on Wed 11 Nov 2015. Prior version did not exhibit the issue.
Did you clear the cache?
Created attachment 95572 [details] Output of thread apply all bt Hang when hover mouse over literal "true".
(In reply to Sven Brauch from comment #4) > Did you clear the cache? Not on this instance, but I did on other instances. Will still occur immediately after clearing cache.
To me, the original problem also occurred after clearing the cache.
I think these are two separate issues, actually. The one with the backtrace in python I sort of understand, but I would need example code which causes this to investigate. The second backtrace looks entirely different, and should be put into a new report.
Created attachment 95576 [details] Another output of thread apply all bt
Created attachment 95577 [details] And another bt
(In reply to Sven Brauch from comment #8) > I think these are two separate issues, actually. The one with the backtrace > in python I sort of understand, but I would need example code which causes > this to investigate. The second backtrace looks entirely different, and > should be put into a new report. Will you be splitting the issues? Or would you like me to open a new one?
Would be easiest if you opened a new one. Thanks. The two backtraces look identical to the first one. The ThreadWeaver one is very weird ...
So, to pursue this further I would need some example code to reproduce the problem. The issue from the python backtraces looks like it is triggered by some specific code. Can you tell me which project is loaded in KDevelop, if it's openly available?
The source code is not available, sorry about that. If you'd want specific logging / tracing to be added and can provide a patch for that, I'm willing to include it and rebuild Kdevelop.
Hard to say poking in the dark. What it hangs at is creating a string representation of an "unsure type", which is created when a variable can have multiple values. Is the value you hover over maybe a function which is called in a lot of places with lots of different arguments, or so?
Hi Sven. Sorry to take so long to get back to you on this; I've been heads down on a customer outage. I have opened Bug 355854 as you asked.
We keep seeing this behaviour every day, quite annoying. Despite that, we have not found what actually triggers it. Not sure if it's related, but one thing we noticed is that whenever we use the word "connect" in a python file, it is always rendered Bold in a blue-ish color, independent of how and when the word is used. Expectation would be that only the definition would be bold, and that there would be variation in the colour used. Is there a reason for this special treatment?
That is not related, that's just kate's Qt highlighting. It's a bit weird, but you can ignore it, it is harmless. I'm sorry for the inconvenience, but without a way to reproduce I can't really fix it. If you need a quick workaround, delete line 57 in duchain/unsuretype.cpp. You will lose a bit of type tracking accuracy but probably not much.
sorry, duchain/types/unsuretype.cpp is the file name. The line is results.append(resolved.cast<UnsureType>()->typesRecursive()); That apparently runs into a (near?) infinite recursion, but I'm not sure how. To find out I'd need some example code which creates a type which triggers this behaviour.
The suggested workaround fixes the problem. Not sure exactly what functionality is gone now because of this. Anyway, this fix needs to be in!
Nah, this is not a proper fix for the problem. I need to know where the issue originates from ...
*** This bug has been marked as a duplicate of bug 358563 ***