After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 690114 - Program halts execution when terminal window is hidden
Program halts execution when terminal window is hidden
Status: RESOLVED DUPLICATE of bug 794214
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal minor
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-12-12 17:53 UTC by dhekir
Modified: 2018-10-25 18:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description dhekir 2012-12-12 17:53:20 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.
Comment 1 Christian Persch 2013-01-14 17:35:33 UTC
Looks like a dup of one of bug 350015, bug 439247, bug 532816 or bug 572210.
Comment 2 dhekir 2013-01-14 18:07:28 UTC
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.
Comment 3 Justin Lebar 2016-04-23 04:47:27 UTC
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.
Comment 4 Christian Persch 2016-04-23 07:38:29 UTC
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) ?
Comment 5 Justin Lebar 2016-04-25 23:20:53 UTC
Wow, building gnome is complicated.

I am trying.  This may take me some time.  :)
Comment 6 Christian Persch 2018-03-11 18:22:38 UTC
Possibly a duplicate of bug 794214 ?
Comment 7 Egmont Koblinger 2018-10-25 18:43:55 UTC
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 ***