Red Hat Bugzilla – Bug 1017302
mingw-virt-viewer crashes after 10+ MB plain text is copied to clipboard in the guest
Last modified: 2014-03-04 13:29:39 EST
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 Event Name: APPCRASH
Application Name: remote-viewer.exe
Application Version: 188.8.131.52
Application Timestamp: 524c356d
Fault Module Name: libglib-2.0-0.dll
Fault Module Version: 184.108.40.206
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:
If the online privacy statement is not available, please read our privacy statement offline:
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 - 220.127.116.1101 (signed 2013/07/07)
-- does not happen with 3.2 agent
Steps to Reproduce:
1. have 10+ MB plain text in guest, select it
2. copy the text
mingw-remote-viewer should work
(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.
The agent works normally after reconnection so I suspected the client. I'll look into the logs tomorrow.
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? ;)
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.
#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)
#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)
#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)
#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)
#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)
#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)
#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,
(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.
agent bug: bug 1017790
(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.
I sent a 3-patch series fixing the crash:
devel ack, for "g_main_loop_is_running: assertion `g_atomic_int_get (&loop->ref_count) > 0' failed" crash.
(allocation failure is handled in bug 1017250)
*** Bug 1034386 has been marked as a duplicate of this bug. ***
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:
Thanks in advance.
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.
*** Bug 998748 has been marked as a duplicate of this bug. ***