Bug 174713 - newly-created tabs are often "frozen"
newly-created tabs are often "frozen"
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gnome-terminal (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Behdad Esfahbod
bzcl34nup
:
Depends On:
Blocks: FC7Target
  Show dependency treegraph
 
Reported: 2005-12-01 12:08 EST by Zack Cerza
Modified: 2008-05-06 20:18 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:18:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 125364 None None None Never

  None (edit)
Description Zack Cerza 2005-12-01 12:08:25 EST
Description of problem:
When a new tab is created, it is often "frozen" in that the contents of the
terminal is not updated until the user switches to a previously-working tab and
back again. Commands do work - typing 'exit<CR>' closes the frozen tab.

In one of my current terminal windows open now, 14 out of 17 tabs are frozen.

Version-Release number of selected component (if applicable):
gnome-terminal-2.12.0-2.x86_64

How reproducible:
Almost always.

Steps to Reproduce:
1. Open gnome-terminal
2. Create a new tab
3. Type stuff.
  
Actual results:
Nothing shows up.

Expected results:
The stuff you type shows up.

Additional info:
Comment 1 Dave Malcolm 2005-12-06 15:59:59 EST
Seeing similar symptoms on i386
gnome-terminal-2.12.0-2
vte-0.11.15-1.fc5

Seems to affect some tabs, but not others.  I've taken to opening tabs until I
get an unaffected tab, then going back and closing the tabs that are affected.
Comment 2 Dave Malcolm 2005-12-06 16:13:58 EST
I also sometimes get an entirely blank black tab; switching tabs forwards and
back gets the tab redrawn, but such a tab is still affected by the bug.
Comment 3 Dave Malcolm 2005-12-06 17:43:09 EST
Looks like a repaint/expose problem; if you drag a window over one of the tabs,
it repaints the stuff in the terminal tab that's changed.
e.g. type "ls"<ENTER> in one of the tabs; nothing appears to happen; no keypress
feedback, but drag a window in front to force repainting and you see the results
of your ls (and the entry of the command)
Comment 4 Ray Strode [halfline] 2006-01-11 14:55:39 EST
Hey Dave, Zack,

Are you guys still seeing this?
Comment 5 Zack Cerza 2006-01-11 18:28:09 EST
The last time I used the machine was Friday, and I was seeing it then.
Comment 6 Ray Strode [halfline] 2006-01-27 16:05:32 EST
how about now?
Comment 7 Zack Cerza 2006-01-30 20:00:46 EST
Same.

gnome-terminal-2.13.3-1.x86_64
vte-0.11.16-2.fc5.1.x86_64
Comment 8 Matthias Clasen 2006-02-14 15:23:43 EST
http://bugzilla.gnome.org/show_bug.cgi?id=125364
seems to be an upstream bug tracking this issue.
Given that it is an old issue, and rare, move to FC6Target
Comment 9 Zack Cerza 2006-02-14 16:12:05 EST
Maybe it's 'rare' for i386 users... but I reproducibly have to create 15-20
unusable new tabs for each usable one on my x86_64 boxes. Ouch.

Explicitly adding the GNOME bug as a reference.
Comment 10 Matthias Clasen 2006-07-06 18:02:03 EDT
Add to FC6Destop tracker
Comment 11 Matthias Clasen 2006-08-23 22:54:38 EDT
Zack, are you still seeing this on x68_64 ? I have not been able to reproduce it
on i386
Comment 12 Zack Cerza 2006-08-24 10:48:40 EDT
Matthias, yes I am. I can show you today if you want.
Comment 13 Behdad Esfahbod 2006-08-24 11:32:06 EDT
You see this in devel?!
Comment 14 Zack Cerza 2006-08-24 11:45:25 EDT
Behdad, yes. I'm sorry.

I don't think I ever saw it in FC5, which I was using for a while on this
system, but I can reliably reproduce it in rawhide. I'll do it again right now.
There. :)
Comment 15 Matthias Clasen 2006-09-21 15:02:53 EDT
Hmm, I just opened 50 tabs on our x86_64 test machine, which has a pretty recent
rawhide, and not a single one froze.

Zack, you still see this ? 
Comment 16 Zack Cerza 2006-09-25 13:23:50 EDT
Yes, I'm still seeing it. A lot. :(
Comment 17 Erik van Pienbroek 2006-09-25 18:02:14 EDT
I'm also noticing this bug with my x86_64 machine running rawhide
Comment 18 sean 2006-11-17 18:01:24 EST
gnome-terminal-2.16.1-1.fc7.x86_64

Any new tab is frozen. Always.

This started for me after fc6.

sean
Comment 19 sean 2006-12-06 17:51:43 EST
installing

gnome-terminal-2.16.0-2.fc6.x86_64

as an old package fixes this.

Is this an upsteam issue? only on x86-64?

Comment 20 Matěj Cepl 2007-03-07 10:22:05 EST
I can fully reproduce it on x86_64 RHEL-5-Gold, but when I switched off ATK,
things are suddenly OK (the idea with ATK is from bug 224611, which is quite
similar).
Comment 21 Erik van Pienbroek 2007-03-07 10:33:04 EST
A while ago I was already having this problem. After a reinstall everything
worked fine for a while, but since a few weeks the problem has returned, though
it is a little bit different behaviour this time. The first time the problem was
that
newly created tabs are often frozen (as the title of this bugzilla entry says
:P), but this time the problem occurs a while after creating a new tab. The
scrollbar itself behaves fine, but the terminal itself isn't getting any screen
refreshes. Terminal I/O seems to work just fine, it's just the screen refreshes
that are broken.
Comment 22 Mladen Kuntner 2007-03-13 18:26:01 EDT
Just want to say me to.
On a updated rawhide with
gnome-terminal-2.17.92-1.fc7

I think i first saw that after fresh FT2 install.
Comment 23 Bug Zapper 2008-04-03 12:40:03 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 24 Bug Zapper 2008-05-06 20:18:27 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.