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.

Created attachment 83971 [details]
gdb backtrace

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

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 :-)

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.

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

Created attachment 83998 [details]
debug output

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 ;-]

Ok, that log does indeed show that we didn't receive a VisibilityNotify after the desktop switch.

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

Chris.

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


-Joseph

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.

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

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.

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.

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.

I can confirm the tab issue using a clean build of GARNOME-2.18.0.

-Joseph

(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?

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.

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

Created attachment 84590 [details]
debug output for tab-switching  window visability problem

Chris,

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

-Joseph

Created attachment 84592 [details]
xtrace log for desktop-switching tab expose problem

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.

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?

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

Note according to seb128 there is an ubuntu bug about this, too.

https://beta.launchpad.net/ubuntu/+source/vte/+bug/92405

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.

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.

Created attachment 84869 [details] [review]
Do not force visibility state on toplevel events

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

*poke*  Patch still not committed and 0.16.2 released without it?

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.

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.

The current code in svn-trunk, version 1883, does *not* solve the problem. Reopening the bug.

-Joseph

* 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.

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

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

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.

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

Still relevant?

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!

Chris, can you take another look into this?

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...

Not reproducible, no response -> closing.