Bug 856682

Summary:

[remote-viewer] gnome session unresponsive after connecting to vm with more displays

Product:

Red Hat Enterprise Linux 6

Reporter:

Tomas Jamrisko <tjamrisk>

Component:

virt-viewer

Assignee:

Christophe Fergeau <cfergeau>

Status:

CLOSED ERRATA

QA Contact:

Virtualization Bugs <virt-bugs>

Severity:

urgent

Docs Contact:

Priority:

high

Version:

6.3

CC:

acathrow, bsanford, cfergeau, codong, cwei, dblechte, juzhou, lcui, lnovich, marcandre.lureau, mjenner, mzhan, tzheng

Target Milestone:

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

virt-viewer-0.5.6-1.el6

Doc Type:

Bug Fix

Doc Text:

Because of what apparently is a gtk+2 bug , we cannot recreate the submenu every time we need to refresh it, otherwise the application may get frozen with the keyboard and mouse grabbed if gtk_menu_item_set_submenu is called while the menu is displayed. Reusing the same menu every time works around this issue. Cause: Recreating a menu while it being display, for example clicking View -> Displays before the connection actually gets established and leave it open. Consequence: Client may freeze. Fix: Do not recreate entirely a Gtk+ menu, but instead repopulate it. Result: Client doesn't freeze when refreshing display menu.

Story Points:

---

Clone Of:

Clones:

912434 922712 926007 927882 (view as bug list)

Environment:

Last Closed:

2013-11-21 08:01:53 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

926007

Bug Blocks:

922712, 927882

Attachments:

Description	Flags
Standalone gtk+2 testcase reproducing this problem	none

Description Tomas Jamrisko 2012-09-12 14:58:23 UTC

Description of problem:
Connecting to a VM with more displays whilst having View -> Displays expanded before the connection gets actually established results in gnome session being completely unresponsive to user input

Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-9.el6.x86_64
virt-viewer-0.5.2-9.el6.i386
spice-gtk-0.11-11.el6_3.1

How reproducible:
Always

Steps to Reproduce:
1. Setup a VM (preferably in RHEVM) with 2 active screens
2. Click Console in RHEVM (or conenct to the VM any other way)
3. Click View ->, expand Displays before the connection actually gets established and leave it open
4. Wait for the connection to establish
  
Actual results:
Both displays get open, menu doesn't update, session gets frozen, remote-viewer must be killed in order to regain control.

Comment 2 Christophe Fergeau 2012-09-12 15:34:04 UTC

Any chance you can try getting a backtrace when remote-viewer is frozen?
You can attach gdb to it after it froze with "gdb --pid $(pidof remote-viewer)", and then "thread apply all bt" will give you a backtrace showing where it's frozen (you may need to use debuginfo-install virt-viewer to get the debug package to get a good backtrace).

Comment 3 Tomas Jamrisko 2012-09-13 10:49:59 UTC

This is pretty much it, i suppose: 

Thread 1 (Thread 0x7f12ab9dd980 (LWP 24601)):
#0  0x00007f12aae99218 in __poll (fds=0x24c0d50, nfds=15, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:83
#1  0x00000039bc23c655 in g_main_context_poll (context=0x22ea620, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2904
#2  g_main_context_iterate (context=0x22ea620, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2586
#3  0x00000039bc23cd55 in IA__g_main_loop_run (loop=0x23da1e0) at gmain.c:2799
#4  0x000000323fd4c307 in IA__gtk_main () at gtkmain.c:1218
#5  0x000000000041c305 in main (argc=1, argv=0x7fff96eb0858) at remote-viewer-main.c:180

Comment 5 Daniel Berrangé 2012-10-11 15:03:11 UTC

Hmm, are you sure remote-viewer had hung at the time you took that stack trace. That trace shows everything operating 100% normally, just waiting for events.

Comment 6 Tomas Jamrisko 2012-10-11 16:32:02 UTC

Not really, that's why I referred to Session in general. 

I can't really check whether or not is remote-viewer responsive (cursor is blinking though), when the rest of the desktop only shows cursor movement and reacts just to ctrl alt F*; where i kill remote viewer. 

That's pretty much the reason why I asked about your opinion whether to move it to gtk2 as, something like, "Mutual exclusion when adding items to currently displayed menu".

Comment 8 Tomas Jamrisko 2013-02-11 13:54:03 UTC

*** Bug 907597 has been marked as a duplicate of this bug. ***

Comment 9 David Blechter 2013-02-21 13:20:28 UTC

Raising the severity and priority of this bug, proposing for 6.4.z due to a significant impact on rhevm 3.2 testing

Comment 11 Christophe Fergeau 2013-03-20 17:00:36 UTC

I could reproduce this with virt-viewer/spice-gtk git master *built with gtk2* on a f18. I've also been able to reproduce this on a RHEL6
This does not happen when built with gtk3, the whole display menu gets closed automatically at some point during the connection.
I've also been able to reproduce by rebooting a VM and keeping that menu open. This happens quite late in the boot process (agent or qxl loading?)
I'm getting the same backtrace as Tomas when everything is hung.
I've done these tests with a win7 guest.
At this point, I'd lean towards a gtk2 bug, but maybe this can be worked around(?)

Comment 12 Christophe Fergeau 2013-03-20 17:16:45 UTC

On my fedora18 the backtrace was actually a bit more comprehensive:

Thread 3 (Thread 0x7fe8166f5700 (LWP 31563)):
#0  0x0000003a88ce998d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000301d247d24 in g_main_context_poll (priority=2147483647, n_fds=3, 
    fds=0x7fe8100010e0, timeout=-1, context=0x9ad370) at gmain.c:3584
#2  g_main_context_iterate (context=0x9ad370, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3285
#3  0x000000301d248182 in g_main_loop_run (loop=0x9ad300) at gmain.c:3484
#4  0x00000035b06cc546 in gdbus_shared_thread_func (user_data=0x9ad340)
    at gdbusprivate.c:277
#5  0x000000301d26b605 in g_thread_proxy (data=0x9dc0f0) at gthread.c:797
#6  0x0000003a89007d15 in start_thread (arg=0x7fe8166f5700)
    at pthread_create.c:308
#7  0x0000003a88cf246d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114

Thread 2 (Thread 0x7fe814a2a700 (LWP 31566)):
#0  0x0000003a88ce998d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000301d247d24 in g_main_context_poll (priority=2147483647, n_fds=1, 
    fds=0x7fe8080010c0, timeout=-1, context=0xa69a50) at gmain.c:3584
#2  g_main_context_iterate (context=context@entry=0xa69a50, block=block@entry=
    1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3285
#3  0x000000301d247e44 in g_main_context_iteration (context=0xa69a50, 
    may_block=1) at gmain.c:3351
#4  0x00007fe814a3e48d in dconf_gdbus_worker_thread ()
   from /usr/lib64/gio/modules/libdconfsettings.so
#5  0x000000301d26b605 in g_thread_proxy (data=0xa3eed0) at gthread.c:797
#6  0x0000003a89007d15 in start_thread (arg=0x7fe814a2a700)
    at pthread_create.c:308
#7  0x0000003a88cf246d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114

Thread 1 (Thread 0x7fe8232f09c0 (LWP 31560)):
#0  0x0000003a88ce998d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000301d247d24 in g_main_context_poll (priority=2147483647, n_fds=15, 
    fds=0xae4220, timeout=-1, context=0x884be0) at gmain.c:3584
#2  g_main_context_iterate (context=0x884be0, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3285
#3  0x000000301d248182 in g_main_loop_run (loop=0x93fde0) at gmain.c:3484
#4  0x0000003d3cf4b077 in IA__gtk_main () at gtkmain.c:1257
#5  0x000000000040e3c7 in main (argc=1, argv=0x7fff46571958)
    at remote-viewer-main.c:316

Comment 13 Christophe Fergeau 2013-03-20 17:22:39 UTC

(thread 2 is about dconf, not sure at all the 2 additional threads are relevant at all).

Comment 14 Christophe Fergeau 2013-03-21 09:52:51 UTC

G_MESSAGES_DEBUG=all log before dying is below, should be possible to use this to debug further )

(remote-viewer:18130): GSpiceController-DEBUG: controller.vala:178: got CONNECT request
(remote-viewer:18130): GSpiceController-DEBUG: controller.vala:246: new message 17size 8
(remote-viewer:18130): GSpiceController-DEBUG: controller.vala:182: got SHOW request

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
(remote-viewer:18130): GSpice-DEBUG: #0 +0+0-1152x864

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
(remote-viewer:18130): GSpice-DEBUG: #0 +0+0-1152x864

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

(remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

Comment 15 Christophe Fergeau 2013-03-21 10:23:14 UTC

Actually, the (remote-viewer:18130): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed warnings only appear when moving the mouse when everything is frozen ('frozen' = keyboard/mouse(?) grabbed, so screen is refreshing, but you can't interact with anything else). This is consistent with what is happening on screen as when things freeze, the submenu listing the available displays becomes blank (before it was populated), so consistent with 'widget should be displayed here, but is unrealized for whatever reason).

Comment 16 Christophe Fergeau 2013-03-22 17:27:55 UTC

Created attachment 714691 [details]
Standalone gtk+2 testcase reproducing this problem

This is indeed a gtk+2 bug, the attached testcase reproduce this bug by opening the submenu and then waiting for the refresh to happen. The issue appears after the call to gtk_menu_item_set_submenu.
If we reuse the existing submenu, empty it and add the new content instead of recreating the submenu everytime and setting it with _set_submenu, then the bug does not occur. I'll send such a workaround for virt-viewer.

Comment 17 Christophe Fergeau 2013-03-23 08:28:32 UTC

Patch sent upstream https://www.redhat.com/archives/virt-tools-list/2013-March/msg00133.html

Comment 23 CongDong 2013-07-11 08:51:44 UTC

I can reproduce this bug:
Version:
# rpm -qa virt-viewer
virt-viewer-0.5.2-16.el6.x86_64
# rpm -qa gtk2
gtk2-2.18.9-10.el6.x86_64
# rpm -qa spice-gtk
spice-gtk-0.14-4.el6.x86_64

Steps:
As the steps in descritpion

Result:
Both displays get open, menu doesn't update, session gets frozen, remote-viewer must be killed in order to regain control.

Verify:
# rpm -qa spice-gtk gtk2 virt-viewer
spice-gtk-0.14-7.el6.x86_64
gtk2-2.18.9-12.el6.x86_64
virt-viewer-0.5.6-1.el6.x86_64

Steps:
As the steps above.

Result:
The virt-viewer works well, the window and menu didn't get frozen.

As the result, change to VERIFIED.

Comment 24 errata-xmlrpc 2013-11-21 08:01:53 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1578.html