Bug 1017302 - mingw-virt-viewer crashes after 10+ MB plain text is copied to clipboard in the guest
Summary: mingw-virt-viewer crashes after 10+ MB plain text is copied to clipboard in t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.3.0
Assignee: Marc-Andre Lureau
QA Contact: Desktop QE
URL:
Whiteboard:
: 998748 1034386 (view as bug list)
Depends On:
Blocks: 1029162
TreeView+ depends on / blocked
 
Reported: 2013-10-09 15:22 UTC by David Jaša
Modified: 2014-03-04 18:29 UTC (History)
8 users (show)

Fixed In Version: mingw-virt-viewer-0.5.6-15.el6_5
Doc Type: Bug Fix
Doc Text:
Previously virt-viewer would not properly detect agent disconnections, so it crashed when the guest SPICE agent terminated. virt-viewer now properly detects and handles agent disconnections, and no longer crashes on such events.
Clone Of:
Environment:
Last Closed: 2014-01-21 14:47:12 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
remote-viewer --spice-debug output (70.98 KB, text/plain)
2013-10-09 15:22 UTC, David Jaša
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0034 0 normal SHIPPED_LIVE mingw-virt-viewer enhancement update 2014-01-21 19:41:37 UTC

Description David Jaša 2013-10-09 15:22:03 UTC
Created attachment 809996 [details]
remote-viewer --spice-debug output

Description of problem:
mingw-virt-viewer crashes during guest to client copy/paste of 33MB plain text with this output:
(remote-viewer.exe:1164): GSpice-WARNING **: agent status changed, cancel clipboard request
output with --spice-debug is attached

Windows then shows "... stopped working" dialog with these "problem details":
Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	remote-viewer.exe
  Application Version:	1.0.0.0
  Application Timestamp:	524c356d
  Fault Module Name:	libglib-2.0-0.dll
  Fault Module Version:	2.32.4.0
  Fault Module Timestamp:	50350914
  Exception Code:	c0000005
  Exception Offset:	00032880
  OS Version:	6.1.7601.2.1.0.256.4
  Locale ID:	1033
  Additional Information 1:	0a9e
  Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:	0a9e
  Additional Information 4:	0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt



The steps are actually similar to bug 1017294.

Version-Release number of selected component (if applicable):
mingw-virt-viewer-0.5.6-6.el6_64 (win7 32b)
vdagent form RHEV Tools 3.3-6 - 1.1.3.3001 (signed 2013/07/07)
    -- does not happen with 3.2 agent

How reproducible:
always

Steps to Reproduce:
1. have 10+ MB plain text in guest, select it
2. copy the text
3.

Actual results:
mingw-remote-viewer crashes

Expected results:
mingw-remote-viewer should work

Additional info:

Comment 1 Marc-Andre Lureau 2013-10-09 15:31:51 UTC
(remote-viewer.exe:2116): GSpice-DEBUG: ../../gtk/channel-main.c:1367 agent connected: no
(remote-viewer.exe:2116): GSpice-DEBUG: ../../gtk/channel-main.c:1367 agent connected: yes

(remote-viewer.exe:2116): GSpice-WARNING **: agent status changed, cancel clipboard request

Agent crashed? you should open another bug for that (try to get the backtrace).

It's not surprising that this code path as not been well tested.

Comment 2 David Jaša 2013-10-09 15:38:52 UTC
The agent works normally after reconnection so I suspected the client. I'll look into the logs tomorrow.

Comment 3 David Jaša 2013-10-10 13:23:06 UTC
The agent indeed exits and is respawned:
284::INFO::2013-10-10 13:18:43,260::VDAgent::write_completion::vio_serial write completion error 554
284::INFO::2013-10-10 13:18:43,260::VDAgent::run::Agent stopped
1976::INFO::2013-10-10 13:18:46,307::VDAgent::run::***Agent started in session 2***

but that shouldn't make spice-gtk crash anyway, should it? ;)

Comment 4 Marc-Andre Lureau 2013-10-10 13:26:53 UTC
I managed to reproduce on fedora, backtrace:

(lt-spicy:11904): GSpice-DEBUG: spice-channel.c:2602 test cap 0 in 0x1: yes
(lt-spicy:11904): GSpice-DEBUG: spice-util.c:241 spice_make_scancode:  scancode 28
(lt-spicy:11904): GSpice-DEBUG: spice-util.c:241 spice_make_scancode: release scancode 28

(lt-spicy:11904): GSpice-WARNING **: agent status changed, cancel clipboard request

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6d29148 in g_main_loop_is_running (loop=0x4) at gmain.c:3952
warning: Source file is more recent than executable.
3952	 * 
(gdb) bt
#0  0x00007ffff6d29148 in g_main_loop_is_running (loop=0x4) at gmain.c:3952
#1  0x00007ffff7dc876c in clipboard_agent_connected (ri=0x7e9dd0) at spice-gtk-session.c:605
#2  0x00007ffff7039fc5 in g_cclosure_marshal_VOID__PARAM (closure=0x958160, return_value=0x0, 
    n_param_values=2, param_values=0x7fffffff8a50, invocation_hint=0x7fffffff8980, 
    marshal_data=0x0) at gmarshal.c:1042
#3  0x00007ffff7035a13 in g_closure_invoke (closure=0x958160, return_value=0x0, 
    n_param_values=2, param_values=0x7fffffff8a50, invocation_hint=0x7fffffff8980)
    at gclosure.c:777
#4  0x00007ffff7053bba in signal_emit_unlocked_R (node=0x625820, detail=1167, instance=0x7e9dd0, 
    emission_return=0x0, instance_and_params=0x7fffffff8a50) at gsignal.c:3582
#5  0x00007ffff7052e06 in g_signal_emit_valist (instance=0x7e9dd0, signal_id=1, detail=1167, 
    var_args=0x7fffffff8d28) at gsignal.c:3326
#6  0x00007ffff7053359 in g_signal_emit (instance=0x7e9dd0, signal_id=1, detail=1167)
    at gsignal.c:3382
#7  0x00007ffff703ce15 in g_object_dispatch_properties_changed (object=0x7e9dd0, n_pspecs=1, 
    pspecs=0x7fffffff8e60) at gobject.c:1047
#8  0x00007ffff703d0b4 in g_object_notify_by_spec_internal (object=0x7e9dd0, pspec=0x80b370)
    at gobject.c:1141
#9  0x00007ffff703d20e in g_object_notify (object=0x7e9dd0, 
    property_name=0x7ffff7b7b57f "agent-connected") at gobject.c:1183
#10 0x00007ffff7a80988 in notify_main_context (opaque=0x7fffee9bd7b0) at gio-coroutine.c:241
#11 0x00007ffff6d2a4b3 in g_idle_dispatch (source=0x7feb90, 
    callback=0x7ffff7a8094b <notify_main_context>, user_data=0x7fffee9bd7b0) at gmain.c:5250
#12 0x00007ffff6d27cb7 in g_main_dispatch (context=0x64bb20) at gmain.c:3065
#13 0x00007ffff6d28a0e in g_main_context_dispatch (context=0x64bb20) at gmain.c:3641
#14 0x00007ffff6d28c00 in g_main_context_iterate (context=0x64bb20, block=1, dispatch=1, 
    self=0x7ffcf0) at gmain.c:3712
#15 0x00007ffff6d29029 in g_main_loop_run (loop=0x71c8a0) at gmain.c:3906
#16 0x00007ffff7dc8a10 in clipboard_get (clipboard=0x7b1b60, selection_data=0x7fffffff9760, 
    info=2, user_data=0x637a70) at spice-gtk-session.c:648
#17 0x00007ffff7035a13 in g_closure_invoke (closure=0x7f1040, return_value=0x0, 
    n_param_values=4, param_values=0x7fffffff92e0, invocation_hint=0x7fffffff9210)
    at gclosure.c:777
#18 0x00007ffff7053bba in signal_emit_unlocked_R (node=0x62ff00, detail=0, instance=0x81fb60, 
    emission_return=0x0, instance_and_params=0x7fffffff92e0) at gsignal.c:3582
#19 0x00007ffff7052e06 in g_signal_emit_valist (instance=0x81fb60, signal_id=50, detail=0, 
    var_args=0x7fffffff95f8) at gsignal.c:3326
#20 0x00007ffff70534c5 in g_signal_emit_by_name (instance=0x81fb60, 
    detailed_signal=0x32c1bb5b26 "selection-get") at gsignal.c:3422
#21 0x00000032c19f645b in gtk_selection_invoke_handler (widget=0x81fb60, data=0x7fffffff9760, 
    time=839927499) at gtkselection.c:3019
#22 0x00000032c19f7f38 in _gtk_selection_request (widget=0x81fb60, event=0x981460)
    at gtkselection.c:2419
#23 0x00000032c198b38e in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x62fdb0, 
    return_value=0x7fffffff9a60, instance=<optimized out>, args=<optimized out>, 
    marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x62fde0)
    at gtkmarshalers.c:130
#24 0x00007ffff70360e8 in g_type_class_meta_marshalv (closure=0x62fdb0, 
    return_value=0x7fffffff9a60, instance=0x81fb60, args=0x7fffffff9c08, marshal_data=0x208, 
    n_params=1, param_types=0x62fde0) at gclosure.c:997
#25 0x00007ffff7035cab in _g_closure_invoke_va (closure=0x62fdb0, return_value=0x7fffffff9a60, 
    instance=0x81fb60, args=0x7fffffff9c08, n_params=1, param_types=0x62fde0) at gclosure.c:840
#26 0x00007ffff7052182 in g_signal_emit_valist (instance=0x81fb60, signal_id=47, detail=0,

Comment 5 Marc-Andre Lureau 2013-10-10 13:27:46 UTC
(In reply to David Jaša from comment #3)
> The agent indeed exits and is respawned:
> 284::INFO::2013-10-10 13:18:43,260::VDAgent::write_completion::vio_serial
> write completion error 554
> 284::INFO::2013-10-10 13:18:43,260::VDAgent::run::Agent stopped
> 1976::INFO::2013-10-10 13:18:46,307::VDAgent::run::***Agent started in
> session 2***
> 
> but that shouldn't make spice-gtk crash anyway, should it? ;)

clearly, no. Please open a bug for windows vdagent, add a dep for reference.

Comment 6 David Jaša 2013-10-10 14:01:09 UTC
agent bug: bug 1017790

Comment 7 David Jaša 2013-10-10 14:23:38 UTC
(In reply to Marc-Andre Lureau from comment #4)
> I managed to reproduce on fedora ...

FWIW, when using RHEL 6.5 client, the vdagent exit isn't 100 % and the client doesn't crash, client console shows just:
(virt-viewer:950): GSpice-WARNING **: agent status changed, cancel clipboard request
(virt-viewer:950): GLib-CRITICAL **: g_main_loop_is_running: assertion `g_atomic_int_get (&loop->ref_count) > 0' failed

but the client continues running just fine.

Comment 8 Marc-Andre Lureau 2013-10-10 15:56:31 UTC
I sent a 3-patch series fixing the crash:
http://lists.freedesktop.org/archives/spice-devel/2013-October/014903.html

Comment 9 Marc-Andre Lureau 2013-11-06 10:44:56 UTC
devel ack, for "g_main_loop_is_running: assertion `g_atomic_int_get (&loop->ref_count) > 0' failed" crash.

Comment 10 Marc-Andre Lureau 2013-11-06 10:59:05 UTC
(allocation failure is handled in bug 1017250)

Comment 12 Vaclav Ehrlich 2013-11-26 10:11:04 UTC
*** Bug 1034386 has been marked as a duplicate of this bug. ***

Comment 14 Charlie 2013-11-28 01:26:22 UTC
This bug is currently attached to errata RHEA-2013:15512. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 16 errata-xmlrpc 2014-01-21 14:47:12 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-2014-0034.html

Comment 17 Marc-Andre Lureau 2014-03-04 18:29:39 UTC
*** Bug 998748 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.