Version: Konsole: 2.3.3 (using KDE 4.3.4) OS: Linux Installed from: Debian testing/unstable Packages Running the following program within konsole: #include <stdio.h> int main() { for (int i = 0; i < 100000000; i++) { fprintf (stderr, "foo %d\n", i); } } leads to a freeze - not single message is printed - no reaction on return. Only after a long time (30 seconds) something happens. If I run the same program in an xterm, the messages are scrolling through, as I would expect from that kind of output.
*** Bug 253314 has been marked as a duplicate of this bug. ***
In my observation, 'hang/freeze' is not quite accurate. Konsole will update its display, but not in a smooth and continuous way. Periodicaly, the display will pause for a few seconds , then it resumes with contents not continuous with previous one. And konsole will take high percent of CPU, 80% in my case. That also applies to stdout.
*** Bug 240561 has been marked as a duplicate of this bug. ***
*** Bug 281299 has been marked as a duplicate of this bug. ***
might be related with bug 154550. See its comment #4.
I see this kind of behaviour too, but then specifically with very long lines (a sipXproxy.log). The lines span about 5-6 rows of my very wide konsole window. The same file scrolls very quickly in xterm. It seems that konsole is taking up the entiry CPU and given the modern cgroup configuration in ubuntu 12.04, the remaining cpu doesn't get used for other windows... :-( /Simon
I also see this. Using Kubuntu 16.04 here. For example, if GStreamer is installed, when I run this in konsole: GST_DEBUG=2,*src*:9 gst-launch-1.0 fakesrc ! fakesink silent=false then output will eventually no longer be printed. For a while, I can press the return key to manually "advance" the log output (perhaps this flushes something inside konsole?), but eventually, it reaches a point where the tab is completely frozen - I can scroll back, and copy text, but keyboard input no longer does anything, and the output is still. The only thing I can do then is to close that tab. This is highly annoying when debugging code, because sometimes, there can be lots of log output, which in turn sometimes triggers this bug.
Traced it down to QTimer stopping emiting timeout() after getting (re)start()-ed around 600-700 times on my system.
Looking at the Qt source, it might be a glib bug. Could maybe someone try with a non-glib Qt?
this is a glib bug (or less probably in the qt glib event thing), I'm unable to reproduce it with «QT_NO_GLIB=1 konsole»
https://bugreports.qt.io/browse/QTBUG-48344 might be relevant
Git commit ac59cc7e007a3ef73a07f3d31d4a9516fd5f56f5 by Martin T. H. Sandsmark. Committed on 16/07/2018 at 11:46. Pushed by sandsmark into branch 'master'. Fix hang on a lot of output from a program Summary: There is a bug in the Qt glib event loop leading to timers never being able to deliver signals. Work around this by disabling the glib event loop. References: http://lists.qt-project.org/pipermail/interest/2015-September/018846.html https://bugreports.qt.io/browse/QTBUG-48344 Test plan: >From the referenced bug: Stefan Westerfeld 2010-03-10 11:40:24 UTC Running the following program within konsole: #include <stdio.h> int main() { for (int i = 0; i < 100000000; i++) { fprintf (stderr, "foo %d\n", i); } } leads to a freeze - not single message is printed - no reaction on return. Only after a long time (30 seconds) something happens. If I run the same program in an xterm, the messages are scrolling through, as I would expect from that kind of output. Reviewers: #konsole, hindenburg Reviewed By: #konsole, hindenburg Subscribers: hindenburg Tags: #konsole Differential Revision: https://phabricator.kde.org/D6078 M +8 -0 src/main.cpp A +15 -0 tests/spam-stderr.c [License: UNKNOWN] * The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://commits.kde.org/konsole/ac59cc7e007a3ef73a07f3d31d4a9516fd5f56f5