| Summary: | IO error on machine shutdown | ||
|---|---|---|---|
| Product: | Spice | Reporter: | Zeeshan Ali <zeenix> |
| Component: | spicec (deprecated) | Assignee: | Spice Bug List <spice-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
There seems to have been a changed of behaviour indeed, spice-gtk 0.22 used to only emit 'closed' events when the other end gets disconnected, while it now emits an IO error followed by a 'closed' event. (In reply to comment #1) > There seems to have been a changed of behaviour indeed, spice-gtk 0.22 used > to only emit 'closed' events when the other end gets disconnected, while it > now emits an IO error followed by a 'closed' event. Ah ok so I guess solution is simply to ignore this if machine is shutoff in Boxes? (In reply to comment #2) > (In reply to comment #1) > > There seems to have been a changed of behaviour indeed, spice-gtk 0.22 used > > to only emit 'closed' events when the other end gets disconnected, while it > > now emits an IO error followed by a 'closed' event. > > Ah ok so I guess solution is simply to ignore this if machine is shutoff in > Boxes? Actually that doesn't work since spice does its thing before Boxes can detect the state change. Even if it did work right now, how can we be sure the events/signals are received from two different sources in a particular order? This seems to be fixed in upstream now: http://cgit.freedesktop.org/spice/spice-gtk/commit/?id=9cd267a9db91aee10459a4a2bbb984663b03dd9e |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I started to get "Connection to %s failed" error on shutting down VMs in Boxes so I investigated a bit and turns out that its because we are getting IO error from spice when machine shuts down. I'm not sure if this is a new behaviour in spice or some recent changes in Boxes exposed this somehow but I talked to teuf and he asked me to provide a backtrace so here I am. :) #0 _boxes_machine_display___lambda78_ (self=0x851800, failed=1) at /home/zeenix/checkout/gnome/gnome-boxes/src/machine.vala:160 #1 0x000000000048819d in __boxes_machine_display___lambda78__boxes_display_disconnected (_sender=0xf17950, connection_failed=1, self=0x851800) at /home/zeenix/checkout/gnome/gnome-boxes/src/machine.vala:152 #2 0x00007ffff44cde4e in g_cclosure_marshal_VOID__BOOLEANv (closure=0x12da3a0, return_value=0x0, instance=0xf17950, args=0x7fffffffcfc8, marshal_data=0x0, n_params=1, param_types=0x12d4850) at gmarshal.c:188 #3 0x00007ffff44caef8 in _g_closure_invoke_va (closure=0x12da3a0, return_value=0x0, instance=0xf17950, args=0x7fffffffcfc8, n_params=1, param_types=0x12d4850) at gclosure.c:831 #4 0x00007ffff44e60dd in g_signal_emit_valist (instance=0xf17950, signal_id=360, detail=0, var_args=0x7fffffffcfc8) at gsignal.c:3218 #5 0x00007ffff44e73bb in g_signal_emit_by_name (instance=0xf17950, detailed_signal=0x53603c "disconnected") at gsignal.c:3405 #6 0x00000000004a9918 in boxes_spice_display_main_event (self=0xf17950, event=SPICE_CHANNEL_ERROR_IO) at /home/zeenix/checkout/gnome/gnome-boxes/src/spice-display.vala:278 #7 0x00000000004a8b99 in _boxes_spice_display_main_event_spice_channel_channel_event (_sender=0x12fb8e0, event=SPICE_CHANNEL_ERROR_IO, self=0xf17950) at /home/zeenix/checkout/gnome/gnome-boxes/src/spice-display.vala:222 #8 0x00007ffff44cea5b in g_cclosure_marshal_VOID__ENUMv (closure=0x12fba80, return_value=0x0, instance=0x12fb8e0, args=0x7fffffffd4d8, marshal_data=0x0, n_params=1, param_types=0x12da1f0) at gmarshal.c:706 #9 0x00007ffff44caef8 in _g_closure_invoke_va (closure=0x12fba80, return_value=0x0, instance=0x12fb8e0, args=0x7fffffffd4d8, n_params=1, param_types=0x12da1f0) at gclosure.c:831 #10 0x00007ffff44e60dd in g_signal_emit_valist (instance=0x12fb8e0, signal_id=370, detail=0, var_args=0x7fffffffd4d8) at gsignal.c:3218 #11 0x00007ffff44e724f in g_signal_emit (instance=0x12fb8e0, signal_id=370, detail=0) at gsignal.c:3365 #12 0x00007ffff6f52861 in do_emit_main_context (object=0x12fb8e0, signum=0, params=0x7fffc3ffea50) at spice-channel.c:749 #13 0x00007ffff6f5a30b in emit_main_context (opaque=0x7fffc3ffe9e0) at gio-coroutine.c:200 #14 0x00007ffff41afcef in g_idle_dispatch (source=0x18799e0, callback=0x7ffff6f5a2c5 <emit_main_context>, user_data=0x7fffc3ffe9e0) at gmain.c:5320 #15 0x00007ffff41ad3f8 in g_main_dispatch (context=0x805160) at gmain.c:3064 #16 0x00007ffff41ae17e in g_main_context_dispatch (context=0x805160) at gmain.c:3663 #17 0x00007ffff41ae370 in g_main_context_iterate (context=0x805160, block=1, dispatch=1, self=0x810b00) at gmain.c:3734 #18 0x00007ffff41ae434 in g_main_context_iteration (context=0x805160, may_block=1) at gmain.c:3795 #19 0x00007ffff47e0e0a in g_application_run (application=0x7ca110, argc=1, argv=0x7fffffffd978) at gapplication.c:2282 #20 0x000000000048ae9e in _vala_main (args=0x7fffffffd978, args_length1=1) at /home/zeenix/checkout/gnome/gnome-boxes/src/main.vala:84 #21 0x000000000048aef1 in main (argc=1, argv=0x7fffffffd978) at /home/zeenix/checkout/gnome/gnome-boxes/src/main.vala:68