I'm using KDevelop 4.6.0 on Fedora 20 with Qt: 4.8.6, KDE Development Platform: 4.12.5. I used the default session and write a simple main function with a while loop that counts to ten. Unfortunately I forgot to increment it and KDevelop becomes unresponsive. The only thing I can do is kill it from the command line. It's a simple while loop without an increment in the main function, nothing more. Logs here: http://paste.fedoraproject.org/109955/84418814 Reproducible: Always Steps to Reproduce: 1. Write an application to create simple while loop using the standard C++ console app template 2. Forget to increment the while loop 3. Execute the program. Actual Results: KDevelop becomes unresponsive and cannot terminate the program Expected Results: KDevelop allows me to terminate the application without crashing itself.
Huh? Does KDevelop freeze or just become unresponsive? Please get us a backtrace: After executing the program, find the PID of KDevelop and do 'gdb --pid <pidof_kdevelop>', type 'bt'. Also see: http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB
I'm terribly sorry for not responding, I some how missed the email that there was activity on this bug. This is the output of `gdb --pid $(pgrep kdevelop` and running `bt` after executing the while loop. KDevelop doesn't crash outright but it does become completely unresponsive. Hope this helps.
you forgot to add the log :)
Also, please make the test app available and list the explicit steps you run to trigger this behavior. I.e., if possible, just attach a sample project (tarball) here and list the steps we should do to reproduce the bug.
Damn, http://paste.fedoraproject.org/111946/03450631 There you go. So I deleted the old project and started from scratch. I created a new project, selected Standard->Terminal, and this is what I wrote in main.cpp #include <iostream> int main(int argc, char **argv) { std::cout << "Hello, world!" << std::endl; int i = 0; while(i < 10) { std::cout << i << std::endl; } return 0; } And then KDevelop becomes unresponsive. I can't really do anything to stop it. I can send SIGTERM and kill it though. One thing I did differently was first, I simply write an infinite loop, without output. Meaning I have 'while (i < 10); ' and it could be stopped. There's really nothing else I did.
Git commit ffe1593192860f80a23c3cd19e53dc59f27623e6 by Milian Wolff. Committed on 22/06/2014 at 17:23. Pushed by mwolff into branch 'master'. Do not resize a view to contents, when we only have one column. This greatly improves the runtime performance of the output widget when a lot of stuff is pushed into it. Not yet optimal, though. M +4 -0 util/focusedtreeview.cpp http://commits.kde.org/kdevplatform/ffe1593192860f80a23c3cd19e53dc59f27623e6
Git commit c541bc7f34c17a82c6270f017d611df8944d6add by Milian Wolff. Committed on 22/06/2014 at 20:21. Pushed by mwolff into branch 'master'. Do not freeze when executing a job with a lot of output. We group the scroll-to-bottom events now which greatly reduces the CPU overhead. Finding the visual rect and/or scrolling to the bottom of a view is expensive, as it requires layouting of all rows. Now, we do this at most ~3times per second, which is much less resource hungry and leaves room for the user to cancel a job. M +51 -14 plugins/standardoutputview/outputwidget.cpp M +9 -1 plugins/standardoutputview/outputwidget.h http://commits.kde.org/kdevplatform/c541bc7f34c17a82c6270f017d611df8944d6add
(In reply to comment #6) > Git commit ffe1593192860f80a23c3cd19e53dc59f27623e6 by Milian Wolff. > Committed on 22/06/2014 at 17:23. > Pushed by mwolff into branch 'master'. > > Do not resize a view to contents, when we only have one column. > > This greatly improves the runtime performance of the output widget > when a lot of stuff is pushed into it. Not yet optimal, though. > > M +4 -0 util/focusedtreeview.cpp > > http://commits.kde.org/kdevplatform/ffe1593192860f80a23c3cd19e53dc59f27623e6 This commit make the output in the build view unusable because long error/warning lines are truncated.
Yes, I know. It's tracked in bug 336606 and I'm working on that right now.