Bug 1126825

+++ This bug was initially created as a clone of Bug #1096721 +++

The bug can also be reproduced on rhel7,so cloned it.
+++ This bug was initially created as a clone of Bug #1096720 +++

Description
Unnecessary warning messages show when shutdown guest during virt-viewer $guest --wait

Version:
virt-viewer-0.5.6-10.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Prepare a running guest,eg:test.

2.Use virt-viewer --wait to launch the guest.
# virt-viewer test --wait

3.In another console or just in guest console,shutdown it.
# virsh destroy test

[snip]

--- Additional comment from tingting zheng on 2014-07-21 04:21:21 EDT ---

Tested with:
virt-viewer-0.6.0-1.el7.x86_64

When use virt-viewer --wait to launch a vnc guest then shutdown guest,no such warning shows as description.

However,when I use virt-viewer or virt-viewer --wait to launch a vnc guest,then shutdown guest,a different error shows as below:

(virt-viewer:20076): Gdk-CRITICAL **: gdk_window_get_width: assertion `GDK_IS_WINDOW (window)' failed

(virt-viewer:20076): Gdk-CRITICAL **: gdk_window_get_height: assertion `GDK_IS_WINDOW (window)' failed

Need the bug to fix this warning or need I file a new bug,thanks.

--- Additional comment from tingting zheng on 2014-07-29 23:09:03 EDT ---

Refer to comment 5,new error info shows,so move the bug to ASSIGNED.

--- Additional comment from Marc-Andre Lureau on 2014-07-30 04:04:50 EDT ---

Christophe, would you like to take a look?

--- Additional comment from Christophe Fergeau on 2014-08-05 05:19:51 EDT ---

This warning is unrelated to the changes in this bug, they also happen without --wait. Backtrace is:

#0  g_logv (log_domain=0x3247a74066 "Gdk", log_level=G_LOG_LEVEL_CRITICAL, 
    format=<optimized out>, args=args@entry=0x7fffffffd1b0) at gmessages.c:1038
#1  0x0000003a97450eff in g_log (
    log_domain=log_domain@entry=0x3247a74066 "Gdk", 
    log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, 
    format=format@entry=0x3a974bee3a "%s: assertion '%s' failed")
    at gmessages.c:1071
#2  0x0000003a97450f39 in g_return_if_fail_warning (
    log_domain=log_domain@entry=0x3247a74066 "Gdk", 
    pretty_function=pretty_function@entry=0x3247a8a320 <__FUNCTION__.33032> "gdk_window_get_width", 
    expression=expression@entry=0x3247a74794 "GDK_IS_WINDOW (window)")
    at gmessages.c:1080
#3  0x0000003247a35ed4 in gdk_window_get_width (window=0x0) at gdkwindow.c:6093
#4  0x00007ffff7dc5e73 in gdk_drawable_get_size (w=0x0, ww=0x7fffffffd2f0, 
    wh=0x7fffffffd2f4) at vncdisplay.c:140
#5  0x00007ffff7dcc183 in vnc_display_set_scaling (obj=0x9661e0 [VncDisplay], 
    enable=1) at vncdisplay.c:2446
#6  0x0000000000425555 in virt_viewer_display_vnc_new (
    vnc=0x9661e0 [VncDisplay]) at virt-viewer-display-vnc.c:191
#7  0x00000000004241b3 in virt_viewer_session_vnc_disconnected (
    vnc=0x9661e0 [VncDisplay], session=0x962560 [VirtViewerSessionVnc])
    at virt-viewer-session-vnc.c:114
#8  0x0000003944a10747 in _g_closure_invoke_va (
    closure=closure@entry=0x6d2480, return_value=return_value@entry=0x0, 
    instance=instance@entry=0x9661e0, args=args@entry=0x7fffffffd560, 
    n_params=0, param_types=0x0) at gclosure.c:831
#9  0x0000003944a299d7 in g_signal_emit_valist (instance=0x9661e0, 
    signal_id=<optimized out>, detail=0, 
    var_args=var_args@entry=0x7fffffffd560) at gsignal.c:3215
#10 0x0000003944a2a63f in g_signal_emit (instance=<optimized out>, 
    signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3363
#11 0x00007ffff7dc9a60 in on_disconnected (conn=0x975cc0 [VncConnection], 
    opaque=0x9661e0) at vncdisplay.c:1568
#12 0x0000003944a10747 in _g_closure_invoke_va (
    closure=closure@entry=0x6d2190, return_value=return_value@entry=0x0, 
    instance=instance@entry=0x975cc0, args=args@entry=0x7fffffffd850, 
    n_params=0, param_types=0x0) at gclosure.c:831
#13 0x0000003944a299d7 in g_signal_emit_valist (instance=0x975cc0, 
    signal_id=<optimized out>, detail=0, 
    var_args=var_args@entry=0x7fffffffd850) at gsignal.c:3215
#14 0x0000003944a2a63f in g_signal_emit (instance=<optimized out>, 
    signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3363
#15 0x00007ffff7ba419c in do_vnc_connection_emit_main_context (
    opaque=0x7fffed16ef40) at vncconnection.c:578
#16 0x0000003a97449c3a in g_main_dispatch (context=0x68d280) at gmain.c:3064
#17 g_main_context_dispatch (context=context@entry=0x68d280) at gmain.c:3663
#18 0x0000003a97449f88 in g_main_context_iterate (context=0x68d280, 
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at gmain.c:3734
#19 0x0000003a9744a25a in g_main_loop_run (loop=0x74c560) at gmain.c:3928

What happens is that upon disconnection, virt-viewer creates a new gtk-vnc display widget. Part of that involves GdkWindow calls, but at this point, the associated GdkWindow is NULL, hence the warnings.
One way around it is :

diff --git a/src/vncdisplay.c b/src/vncdisplay.c
index de3f3ef..de6b4a4 100644
--- a/src/vncdisplay.c
+++ b/src/vncdisplay.c
@@ -2438,8 +2452,13 @@ gboolean vnc_display_set_scaling(VncDisplay *obj,
     obj->priv->allow_scaling = enable;
 
     if (obj->priv->fb != NULL) {
-        gdk_drawable_get_size(gtk_widget_get_window(GTK_WIDGET(obj)), &ww, &wh)
-        gtk_widget_queue_draw_area(GTK_WIDGET(obj), 0, 0, ww, wh);
+        GdkWindow *window = gtk_widget_get_window(GTK_WIDGET(obj));
+
+        if (window != NULL) {
+            gdk_drawable_get_size(gtk_widget_get_window(GTK_WIDGET(obj)),
+                                  &ww, &wh);
+            gtk_widget_queue_draw_area(GTK_WIDGET(obj), 0, 0, ww, wh);
+        }
     }
 
     return TRUE;

Not sure if this is good enough or if we need to dig deeper for the exact sequence of events causing this.

--- Additional comment from Marc-Andre Lureau on 2014-08-05 05:57:03 EDT ---

There are other similar criticals upon connection:

(virt-viewer:29150): Gdk-CRITICAL **: gdk_window_set_cursor: assertion 'GDK_IS_WINDOW (window)' failed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff5888e7b in _g_log_abort (breakpoint=1) at gmessages.c:315
315	    G_BREAKPOINT ();
(gdb) bt
#0  0x00007ffff5888e7b in _g_log_abort (breakpoint=1) at gmessages.c:315
#1  0x00007ffff5889d6d in g_logv (log_domain=0x7ffff702052d "Gdk", log_level=G_LOG_LEVEL_CRITICAL, 
    format=0x7ffff591866f "%s: assertion '%s' failed", args=0x7fffffffcf28) at gmessages.c:1041
#2  0x00007ffff5889e5b in g_log (log_domain=0x7ffff702052d "Gdk", log_level=G_LOG_LEVEL_CRITICAL, 
    format=0x7ffff591866f "%s: assertion '%s' failed") at gmessages.c:1079
#3  0x00007ffff5889e9c in g_return_if_fail_warning (log_domain=0x7ffff702052d "Gdk", 
    pretty_function=0x7ffff7021870 <__FUNCTION__.32080> "gdk_window_set_cursor", 
    expression=0x7ffff70206fe "GDK_IS_WINDOW (window)") at gmessages.c:1088
#4  0x00007ffff6fca6ca in gdk_window_set_cursor (window=0x0, cursor=0x94acc0) at gdkwindow.c:5793
#5  0x0000003f09805c14 in do_framebuffer_init () from /lib64/libgtk-vnc-2.0.so.0
#6  0x0000003f098070dd in on_initialized () from /lib64/libgtk-vnc-2.0.so.0
#7  0x00007ffff676017b in g_cclosure_marshal_VOID__VOIDv (closure=0x8dc8e0, return_value=0x0, 
    instance=0x8d4250, args=0x7fffffffd528, marshal_data=0x0, n_params=0, param_types=0x0) at gmarshal.c:115
#8  0x00007ffff675d3cb in _g_closure_invoke_va (closure=0x8dc8e0, return_value=0x0, instance=0x8d4250, 
    args=0x7fffffffd528, n_params=0, param_types=0x0) at gclosure.c:831
#9  0x00007ffff677858e in g_signal_emit_valist (instance=0x8d4250, signal_id=230, detail=0, 
    var_args=0x7fffffffd528) at gsignal.c:3218
#10 0x00007ffff6779746 in g_signal_emit (instance=0x8d4250, signal_id=230, detail=0) at gsignal.c:3365
#11 0x0000003f09c11a95 in do_vnc_connection_emit_main_context () from /lib64/libgvnc-1.0.so.0


I agree with Christophe, gtk-vnc should learn to handle "widget not realized" state without criticals, restoring itself when it is realized. Working around this in virt-viewer doesn't seem a very good idea. Moving to gtk-vnc.

--- Additional comment from RHEL Product and Program Management on 2014-08-05 06:21:09 EDT ---

This bug report previously had all acks and release flag approved.
However since at least one of its acks has been changed, the
release flag has been reset to ? by the bugbot (pm-rhel).  The
ack needs to become approved before the release flag can become
approved again.

--- Additional comment from Christophe Fergeau on 2014-08-05 07:36:18 EDT ---

Initial bug was in virt-viewer and has been fixed. 
The issues described starting from comment #5 should be moved to a separate gtk-vnc bug.