GNOME Bugzilla – Bug 690114
Program halts execution when terminal window is hidden
Last modified: 2018-10-25 18:43:55 UTC
When running a long program that outputs lots of information on the gnome-terminal, occasionally making the window lose focus (either via clicks or Ctrl+Tab) makes the program halt. It can be resumed by restoring focus on the window. This behavior is not systematic: sometimes the window is obstructed but the program keeps running nevertheless. For instance, the following command can be used to simulate such a program: seq -s" " 1 1000000 In this case, since the output is a single line, it almost always halts when the terminal window loses focus AND it is entirely obstructed by another window. Using smaller lines makes it harder but still possible to reproduce. I could not reproduce it by just partially obstructing the terminal window. Consequently, setting the window as "always on top" prevents the execution from halting. When the window is displayed again, the process and the output are "frozen", and clicking inside the window allows them to resume. This behavior is mildly annoying since it prevents me from having a task running in a obstructed window, if my application outputs lots of information.
Looks like a dup of one of bug 350015, bug 439247, bug 532816 or bug 572210.
I've taken a look at the other bugs, and I'm not entirely sure it is related, since it didn't seem related to a "sluggish" behavior, but more like "if the line is too large, I'll buffer it somewhere", and then it kind of forgot to update the screen afterwards. It did seem more frequent when there long lines of text, and I didn't manage to reproduce it by using short lines. But I don't know about the internals of the terminal, so it might well be related to the others, Although I believe CPU usage was not an issue, on the contrary: when it stopped updating the screen, CPU usage stopped as well. Unfortunately I have not been able to reproduce it on a newer terminal since I upgraded my Fedora, but if I happen to obtain the same result on a newer version, I'll report it.
Hi, resurrecting this old bug. I can reproduce this on demand. It's still fiddly to make it happen, but I have no trouble. I'm using the window manager i3. When hacking on clang, I run $ ninja check-clang which starts a test program, lit, which has a one-line progress bar which it updates very frequently. I then switch to another virtual desktop. Upon switching back to the first virtual desktop, I often (~50% of the time) discover that the output in the terminal is stuck. I can resume the output only by scrolling -- unlike the OP, clicking in the terminal doesn't seem to fix anything. When the output is stuck, the test program does not continue to make progress (presumably because it's blocked on writing to stdout). I've tried a variety of terminal emulators, and I can reproduce with ROXTerm, Terminator, Sakura, and gnome-terminal 3.6.2. I cannot reproduce with xterm, rxvt, and Eterm. I'm told that the common denominator here is vte.
All of these also have in common that they use a very old vte version. Can you repro this in gnome-terminal 3.20 (vte 0.44) ?
Wow, building gnome is complicated. I am trying. This may take me some time. :)
Possibly a duplicate of bug 794214 ?
I'm pretty certain it's a duplicate of bug 794214. Please reopen if still not fixed in vte-0.52.1 or newer. *** This bug has been marked as a duplicate of bug 794214 ***