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 414716 - Refresh issue after changing workspaces
Refresh issue after changing workspaces
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
0.15.x
Other Linux
: Normal normal
: ---
Assigned To: Chris Wilson
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-03-04 22:12 UTC by Joseph Sacco
Modified: 2014-04-27 07:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
gdb backtrace (2.82 KB, text/plain)
2007-03-05 15:33 UTC, Joseph Sacco
  Details
debug output (77.76 KB, text/plain)
2007-03-05 19:17 UTC, Joseph Sacco
  Details
debug output for tab-switching window visability problem (311.99 KB, text/plain)
2007-03-14 18:14 UTC, Joseph Sacco
  Details
xtrace log for desktop-switching tab expose problem (104.00 KB, application/octet-stream)
2007-03-14 18:25 UTC, Joseph Sacco
  Details
Do not force visibility state on toplevel events (564 bytes, patch)
2007-03-19 10:21 UTC, Chris Wilson
committed Details | Review

Description Joseph Sacco 2007-03-04 22:12:29 UTC
Sometimes the terminal window dies. When this occurs, the window does not respond to typing. This happens sometimes when shifting focus to another window and then shifting focus back. This also happens on occasion when the window is resized. 

Once the window is "dead" it cannot be revived and must be closed.

-Joseph
Comment 1 Chris Wilson 2007-03-05 09:08:46 UTC
Joesph, could you attach gdb at the time of the hang and report the backtrace. [You should either start a new gnome-terminal using --disable-factory or use xterm to run gdb.] Thanks.
Comment 2 Joseph Sacco 2007-03-05 15:33:25 UTC
Created attachment 83971 [details]
gdb backtrace
Comment 3 Joseph Sacco 2007-03-05 15:34:32 UTC
Chris,

Sorry for being not providing more data. Being busy is no excuse for being lazy... :-)

Short answer
------------

  The root cause of this problem may be elsewhere.


Longer answer
-------------

System: G4 powerMAC, Fedora FC6 [current], GARNOME-2.17.92

* launch an xterm
* from the xterm start up gnome-terminal from within gdb
=> terminal window appears on the desktop

* resize the gnome-terminal window
=> OK

* switch focus back and forth between xterm and gnome-terminal
=> OK

* switch to a different desktop

* switch back to original desktop
=> xterm is OK

=> gnome-terminal is unresponsive

Note: the menu bar on the gnome-terminal window still works.  It highlights when the gnome-terminal window is given focus.  A new gnome-terminal that works can be launched from that menu bar. The "dead" gnome-terminal can be closed.

* issue ctl-C in gdb
* run backtrace

=> see nothing of consequence

* repeat the exercise to validate problem is associated with desktop switching
=> confirmed

* run 'bt full'
see attached.


NOTE: VT-switching is also broken. This problem may be linuxPPC related.  VT-switching seems to work for other GARNOME users running lintel boxes.
-Joseph
Comment 4 Chris Wilson 2007-03-05 16:08:44 UTC
Thanks for the taking the time to supply this information. The backtrace indicates that the terminal is perfectly healthy and presumably processing input (terminal output, as well as GdkEvents). My guess is that we have missed the visibility notify after the unmap and so believe we are still invisible and avoid updating the display. [But of course that is impossible...]

Could you build vte with debugging enabled [./configure --enable-debugging] and then run gnome-terminal with:
$ VTE_DEBUG_FLAGS=all gnome-terminal --disable-factory 2>g-t-debug.txt

And attach the output. Thanks in advance :-)
Comment 5 Chris Wilson 2007-03-05 19:11:35 UTC
Ok, have a reproducible test case.

Open 2 terminals, switch to another desktop and back.
Only the first terminal updates, the second is totally unresponsive.
Comment 6 Joseph Sacco 2007-03-05 19:16:33 UTC
Chris,

Performed the following sequence:

* uninstall current vte-0.15.6

* build/install vte-0.15.6 with "--enable-debugging" configuration flag set

NOTE: the unstable branch of GARNOME builds with "--enable-debug" set for all apps.  Has the name of the flag changed?

* start the gnome-2.17.92 desktop

* launch an xterm

* from the xterm run

VTE_DEBUG_FLAGS=all /opt/garome/bin/gnome-terminal --disable-factory 2>&1 | tee g-t-debug.txt

NOTE: blinking cursor is shut off to limit the amount of spew.

* switch to another desktop

* switch back to the orginal desktop

* move cursor into gnome-terminal

* type "can you see this?"

No text appears in window while typing.

Debug output attached below.


-Joseph
Comment 7 Joseph Sacco 2007-03-05 19:17:27 UTC
Created attachment 83998 [details]
debug output
Comment 8 Chris Wilson 2007-03-05 20:01:01 UTC
Hmm, fixed a bug with identical symptoms that I introduced into trunk since 0.15.6. Could you check to see if you can reproduce this bug against HEAD?

r1815: 2007-03-05  Chris Wilson  <chris@chris-wilson.co.uk>

	* src/vte.c (_vte_invalidate_cells), (vte_terminal_set_visibility),
	(vte_terminal_paint_area), (vte_terminal_expose):
		Make sure the invalidated_all flag is cleared in the expose
		event if we handle it immediately.

[Bah, mid-air collision. Could you check HEAD, whilst I check your log ;-]
Comment 9 Chris Wilson 2007-03-05 20:37:05 UTC
Ok, that log does indeed show that we didn't receive a VisibilityNotify after the desktop switch.
Comment 10 Joseph Sacco 2007-03-05 20:43:41 UTC
Chris,

OK...

As for the current code in vte-TRUNK...

Short answer: does not resolve the problem

Longer answer:
* gnome-terminal comes up, but does not display its menu bar.

* minimizing and expanding the window
- causes the menu bar to appear [and work]
- leaves the window in state where typing is not visible

Note: The underlying terminal does seem to get whatever is typed.  Typing "quit" will kill the terminal.

* terminal works when it comes up
==> see what you are typing

* switching to another desktop and returning nukes visibility.

-Joseph
Comment 11 Joseph Sacco 2007-03-05 21:02:10 UTC
Chris.

The problem "goes away" when I retreat to vte-0.14.2.


-Joseph
Comment 12 Chris Wilson 2007-03-05 22:53:34 UTC
Joseph, in the course of checking over vte for any silly breaks before the freeze,
I've added a forced visbility_state -> unobscured when the toplevel window is mapped (ie on desktop change).
Can you check and see if g-t is behaving itself again? Thanks.
Comment 13 Joseph Sacco 2007-03-06 02:48:52 UTC
Chris,

Your fix worked... gnome-terminal now behaves when switching desktops back anf forth.  Hopefully a point release for vte is forthcoming.

Now... If you can figure out why VT-switching stopped working on linuxPPC's but not lintel boxes, gnome-life would be good.

-Joseph
Comment 14 Chris Wilson 2007-03-06 12:16:56 UTC
This really seems to be a workaround for a more fundamental bug... However, from a number of reports, it closes this regression.

r1818:  Bug 414716 – gnome-terminal-2.17.92: terminal window dies...

        * src/vte.c (vte_terminal_map_toplevel),
        (vte_terminal_hierarchy_changed):
                Force the visibility state to unobscured after the toplevel is
                remapped.

Comment 15 Deji Akingunola 2007-03-14 05:30:04 UTC
Unfortunately this fix doesn't really solve the problem. If multiple tabs were opened on the gnome-terminal before switching desktops (or minimizing the window), then only the last active tab retains its content, the rest are blanked out after switching desktops.
Comment 16 Chris Wilson 2007-03-14 09:15:51 UTC
Interesting as you should have received a separate VisibilityNotify after switching tabs on the new desktop.

If you can gather an xtrace log, a --gdk-debug-flags=events log and a VTE_DEBUG_FLAGS=events log, it would help pinpoint where the problem occurs. Thanks.
Comment 17 Joseph Sacco 2007-03-14 16:55:06 UTC
I can confirm the tab issue using a clean build of GARNOME-2.18.0.

-Joseph
Comment 18 Deji Akingunola 2007-03-14 17:30:19 UTC
(In reply to comment #16)
> Interesting as you should have received a separate VisibilityNotify after
> switching tabs on the new desktop.
> 
> If you can gather an xtrace log, a --gdk-debug-flags=events log and a
> VTE_DEBUG_FLAGS=events log, it would help pinpoint where the problem occurs.
> Thanks.
> 
Any simple instructions on how to get these?
Comment 19 Chris Wilson 2007-03-14 17:44:07 UTC
Ok, the xtrace is perhaps the most important one:
$ xtrace | tee vte-xtrace.log &
$ DISPLAY=:9 gnome-terminal --disable-factory
This logs all communication with the xserver.

In order to get debug output from vte or GTK+ then you will need to have compiled vte with ./configure --enable-debugging and GTK+ with ./configure --enable-debug
Given debugging versions of those libraries:
$ VTE_DEBUG_FLAGS=all GDK_DEBUG=events $prefix/bin/gnome-terminal \
     --disable-factory 2>&1 | tee vte-debug.txt
This will record all events as they are processed by GTK+ and every action vte performs.
Comment 20 Joseph Sacco 2007-03-14 18:13:19 UTC
Chris,

The problem is more subtle.  I launched an xterm and ran

     VTE_DEBUG_FLAGS=all GDK_DEBUG=events gnome-terminal \
     --disable-factory 2>&1 | tee vte-debug.txt

Next I created two tabs, and ran simple commands like 'ls' and 'pwd' in each window.  Everything looked OK.  I toggled back and forth about ten times. Then I switched back and forth between desktops a few of times.  Viola!!! The evil behavior reappeared.

Trace attached below.

-Joseph
Comment 21 Joseph Sacco 2007-03-14 18:14:47 UTC
Created attachment 84590 [details]
debug output for tab-switching  window visability problem
Comment 22 Joseph Sacco 2007-03-14 18:21:35 UTC
Chris,

I can confirm that switching back and forth between desktops is causing the problem. An xtrace log is attached below.

-Joseph
Comment 23 Joseph Sacco 2007-03-14 18:25:28 UTC
Created attachment 84592 [details]
xtrace log for desktop-switching tab expose problem
Comment 24 Chris Wilson 2007-03-14 19:01:46 UTC
Hmm, the impression I'm getting here is that for some unknown reason gdk stops propagating the VisibilityNotify.

At first:
Gdk-Message: map notify:		window: 39846383
Gdk-Message: visibility notify:	window: 39846383	 full
Visibility (fully-obscured -> unobscured).
change visibility: fully-obscured -> unobscured.
*Invalidating all.
Gdk-Message: expose:		window: 39846383  0	x,y: 0 0  w,h: 1 1
and
Gdk-Message: map notify:		window: 39846383
Gdk-Message: visibility notify:	window: 39846383	 full
Visibility (unobscured -> unobscured).
change visibility: unobscured -> unobscured.
Gdk-Message: expose:		window: 39846383  0	x,y: 0 0  w,h: 1 1

Then later:
Gdk-Message: map notify:		window: 39846383
Gdk-Message: visibility notify:	window: 39846383	 full
Gdk-Message: expose:		window: 39846383  0	x,y: 0 0  w,h: 642 410

It's something to go on at least! Thanks.
Comment 25 Chris Wilson 2007-03-16 12:14:09 UTC
I've spent the morning sync'ing SVN with my tree. One of the fixes that I've pushed concerned a race with processing an immediate expose and initiating the rate-limited updates.

Could you please test HEAD and see if the situation has improved?
Comment 26 Joseph Sacco 2007-03-16 16:22:10 UTC
Chris,

I built and installed vte-trunk [rev #1850] this morning.  I see the same behavior.

I am beginning to wonder if this problem is being caused by something else. I run fedora/rawhide on another disk. The current version of rawhide, which uses most of the packages from GNOME-2.18.0, does not have this problem.

When I get some more free cycles today I will poke around in the fedora SRPM's looking for patches.  Sometimes the fedora patches are slow making it up stream.

-Joseph
Comment 27 Ray Strode [halfline] 2007-03-16 16:26:26 UTC
Note according to seb128 there is an ubuntu bug about this, too.

https://beta.launchpad.net/ubuntu/+source/vte/+bug/92405
Comment 28 Deji Akingunola 2007-03-16 16:32:09 UTC
I can confirm this is probably not a vte issue. I'm also on Fedora rawhide, and something(s) in yesterday's updates seems to have definitely cure the issue for me. I'm guessing it's gtk related.
Comment 29 Steve Grubb 2007-03-16 18:12:00 UTC
I had this bug too. I was using the vte-0.15.6-1 program on rawhide. I upgraded only that package to 0.16.0-1 and the problem went away. Nothing else was updated.
Comment 30 Chris Wilson 2007-03-19 10:21:52 UTC
Created attachment 84869 [details] [review]
Do not force visibility state on toplevel events
Comment 31 Joseph Sacco 2007-03-19 13:39:33 UTC
Chris,

Pat yourself on the back... :-)

I applied your patch [id=84869] to the released 0.16.0 source. The patch solves the problem on my machine [PowerMac /FC6 / GARNOME-2.18.0]  Let's hope that works elsewhere.

-Joseph
Comment 32 Karsten Bräckelmann 2007-04-24 00:23:53 UTC
*poke*  Patch still not committed and 0.16.2 released without it?
Comment 33 Behdad Esfahbod 2007-04-24 00:45:26 UTC
So, Chris, should the patch go in?  Is it the right fix?  (of course moving the code out instead of disabling it).

Also, feel free to rename it to --enable-debug as we discussed previously.
Comment 34 Chris Wilson 2007-04-24 08:44:37 UTC
No, I don't consider this to be the right fix - just a band-aid, though it may as well go into 0.16.x and then try and unbreak it during 0.17.x.

r1880: 2007-04-24  Chris Wilson  <chris@chris-wilson.co.uk>

	Bug 414716 – Refresh issue after changing workspaces

	* src/vte.c (vte_terminal_hierarchy_changed):
		Do not respond to toplevel mapping events.


r1881: 2007-04-24  Chris Wilson  <chris@chris-wilson.co.uk>

	As noted on Bug 414716, the convention is to use --enable-debug
	to enable extra debugging code.

	* configure.in:
		s/debugging/debug/



* makes a note of this bug for future reference.
Comment 35 Joseph Sacco 2007-04-24 21:35:38 UTC
The current code in svn-trunk, version 1883, does *not* solve the problem. Reopening the bug.

-Joseph
Comment 36 Chris Wilson 2007-04-25 07:48:05 UTC
* scratches head.

Do you mind if I ask you to double-check? Otherwise, it means that the catching the unmapping/mapping on workspace switching was a wild goose chase (or merely there is another similar bug)... The only difference between the commit and the patch was the deletion of the excess code instead of just #ifdefing it out. You could also check this assertion by applying the attached patch to 0.16.2.
Comment 37 Joseph Sacco 2007-04-25 14:16:36 UTC
Chris,

What I see:

* released tarball for vte-0.16.2 has the virtual desktop switching problem on my system [G4 PowerMac running latest fedora FC6 + GARNOME-2.19.1]

* released tarball for vte-0.16.2 + patch from comment #30 does not have the virtual desktop switching problem. 

Occasionally, a new tab does not initialize correctly meaning the window is dead-on-arrival. I never get to see the prompt.

* vte SVN-trunk #1883 has the virtual desktop switching problem
Two files in #1883 differ from what is in the released tarball:

- src/vte.c
-src/vtexft.c

The changes to vte.c include the removal of some code per the patch from comment #30 as well as some other changes.


* fedora/rawhide does not have the virtual desktop switching problem on my system [which I find disturbing].

The current version uses
- vte-0.16.2-1.fc7
- gnome-terminal-2.18.0-1.fc7

The vte SRPM has *no* patches. 

gnome-terminal has one patch

   # Fix gnome.org Bug 338913 – Terminal resized when switching tabs
   Patch2: gnome-terminal-2.15.0-338913-revert-336325.patch

diff -u -p -d -r1.124 terminal-window.c
--- gnome-terminal-2.15.0/src/terminal-window.c	4 Mar 2006 06:21:01 -0000	1.124
+++ gnome-terminal-2.15.0/src/terminal-window.c	1 Apr 2006 03:11:46 -0000
@@ -1536,6 +1536,14 @@ terminal_window_set_size_force_grid (Ter
   app = gtk_widget_get_toplevel (widget);
   g_assert (app != NULL);
 
+  /* This set_size_request hack is because the extra size above base
+   * size should only include the width of widgets that intersect the
+   * term vertically and the height of widgets that intersect the term
+   * horizontally. It works around a GTK bug, GTK should handle
+   * this case. The size request can be huge without hosing
+   * anything because we set the MIN_SIZE geometry hint.
+   */
+  gtk_widget_set_size_request (widget, 2000, 2000);
   gtk_widget_size_request (app, &toplevel_request);
   gtk_widget_size_request (widget, &widget_request);



Hmmm... Let me go see what this does.

Stay tuned.


-Joseph
Comment 38 Joseph Sacco 2007-04-25 16:09:01 UTC
Chris,

The fedora/rawhide patch for gnome-terminal does not appear to help.

I have run a number of different experiments today.  The problem is clearly related to expose events and gnome-terminal tabs.  If I do not create tabs, all is well using unpatched versions of vte-0.16.2 and gnome-terminal-2.18.0. 

One thing I do see when using the unpatched versions, is the creation of dead-on-arrival tabs. A DOA tab appears without any text in the window. toggling between tabs will induce some an expose event making the command line prompt appear.  After that point, the tab is unresponsive to the keyboard and stays "dead" no matter what you do.

I am puzzled...

-Joseph
Comment 39 Chris Wilson 2007-04-25 16:22:25 UTC
Joseph, thanks once again for your efforts in testing and refining this bug - it is most appreciated.

Whilst I can't explain DOA terms (yet)... The unresponsive terminal is probably due to the focus being left on the tab label after toggling - that often catches me out.
Comment 40 Joseph Sacco 2007-04-25 16:27:42 UTC
Chris,

A couple of other observations:

* On rare occasion, I do get a DOA tab while running fedora/rawhide.
In the past I have just ignored them and created a new tab.

* I have the GARNOME desktop configured so that a window becomes active when the mouse passes over it. What I see when the mouse is moved onto a different window is the bar at the top of the frame changing color.  What I do *not* see is the color of the block cursor changing from background color to foreground color.  Once a key is pressed, the block cursor does change color.

* Another user of GARNOME-2.18.x on a lintel platform with an older distro does not see the problem, although that user has reported that creating a new tab sometimes blows up gnome-terminal.

Life on the bleeding edge...



-Joseph
Comment 41 Behdad Esfahbod 2010-01-13 19:28:24 UTC
Still relevant?
Comment 42 Yury V. Zaytsev 2011-01-03 13:02:06 UTC
Hi!

Some of the mc users seem to encounter this issue under a disguise. Let me show you how the reproduce it:

1) Download and unpack latest Linux kernel

2) Move the files to another folder or just go for deleting the whole folder recursively

3) mc will start deleting the files, but if you put the window to the background, at some point the vte widget inside Gnome Terminal will hang up completely with no activity inside the terminal

4) Resize the terminal, i.e. maximize it and then un-maximize again: the deletion process will go on.

We have checked with old versions of mc and different terminals (xterm, urxvt etc.). The problem exhibits itself only in gnome-terminal and does not depend on the version of mc.

Please let us know, if you need any more information about this issue.

Thanks!
Comment 43 Behdad Esfahbod 2011-01-05 16:18:38 UTC
Chris, can you take another look into this?
Comment 44 Yury V. Zaytsev 2011-01-10 20:58:13 UTC
Another description of the same problem from mc mailing list:

> On Sat, 2011-01-08 at 19:15 +0200, Satellite wrote:
>
>> In order to catch this bug download any Linux Kernel source archive and
>> untar it somewhere, then fire up Midnight Commander and also be ready to
>> totally overlap gnome-terminal + running mc with some other window, for
>> e.g. Firefox or any other application or File Browser. Then start
>> deleting the unpacked Linux Kernel source directory with F8 in mc and
>> overlap this "gnome-terminal + mc window" with Firefox for example.
>> After you make gnome-terminal window active again you can see that mc is
>> totally unresponsive and the deleting process is also hung...
Comment 45 Christian Persch 2014-04-27 07:40:26 UTC
Not reproducible, no response -> closing.