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:
(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. 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,
(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: http://lists.freedesktop.org/archives/spice-devel/2013-October/014903.html
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: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 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. http://rhn.redhat.com/errata/RHBA-2014-0034.html
*** Bug 998748 has been marked as a duplicate of this bug. ***