Description of problem: When user try to log to VM with *.vv file (native client console invocation method) remote-viewer crashes immediately after xonnect to VM Version-Release number of selected component (if applicable): rhevm 3.6.0.1-0.1 mingw-virt-viewer 2.0-48 How reproducible: always Steps to Reproduce: 1.Log into RHEVM, select Vm, choose Console Invocation as 'Native client' 2.Connect to VM Actual results: remote-viewer crashes Expected results: remote-viewer is working Additional info: After remove [ovirt] section from *.vv file, everything works fine. So I'm not sure if bug is from generating *.vv file (bad ovirt section) OR in virt-viewer or libgobject (could not process ovirt section) Client Windows7 32/64 Guest Any GDB output (gdb) target exec C:\Program Files\VirtViewer v2.0-48\bin\remote-viewer.exe (gdb) run C:\console.vv Starting program: C:\Program Files\VirtViewer v2.0-48\bin\remote-viewer.exe C:\console.vv [New Thread 3504.0x1560] [New Thread 3504.0x15dc] [New Thread 3504.0x132c] [New Thread 3504.0xdc0] [New Thread 3504.0xf4c] [New Thread 3504.0xf40] (remote-viewer.exe:3504): libsoup-WARNING **: Could not set SSL credentials from '/etc/pki/tls/certs /ca-bundle.crt': Failed to open file '/etc/pki/tls/certs/ca-bundle.crt': No such file or directory (remote-viewer.exe:3504): libsoup-WARNING **: Could not set SSL credentials from '/etc/pki/tls/certs /ca-bundle.crt': Failed to open file '/etc/pki/tls/certs/ca-bundle.crt': No such file or directory [New Thread 3504.0x2a8] [New Thread 3504.0xb84] [New Thread 3504.0x1050] (remote-viewer.exe:3504): GSpice-WARNING **: Warning no automount-inhibiting implementation availabl e libgovirt-Message: 'storage_domain' resource with the same name ('iso') already exists Program received signal SIGSEGV, Segmentation fault. 0x63c689ae in ?? () from C:\Program Files\VirtViewer v2.0-48\bin\libgobject-2.0-0.dll (gdb) bt #0 0x63c689ae in ?? () from C:\Program Files\VirtViewer v2.0-48\bin\libgobject-2.0-0.dll #1 0x00000007 in ?? () #2 0x00000007 in ?? () #3 0x00000002 in ?? () #4 0x00000002 in ?? () #5 0x031d56c8 in ?? ()
Just forgot mention that this started after update RHEVM from build 15 to 16
Why is not filed under mingw-virt-viewer component?
I'm not sure why you are debugging a Windows client with gdb, but in any case, debug symbols would have helped get a better stack, I reckon. I'm sure there's a debug build available somewhere.
(In reply to Yaniv Kaul from comment #2) > Why is not filed under mingw-virt-viewer component? Well because if you remove ovirt part from *vv file, mingw-virt-viewer works without segfault. But I guess you mean that portal do everything right so I'll change the component.
Created attachment 1085475 [details] --debug --spice-debug run
Seems to be a mingw-libgovirt problem. #0 g_type_check_instance_is_fundamentally_a ( type_instance=type_instance@entry=0x519b9e0, fundamental_type=fundamental_type@entry=80) at ../../gobject/gtype.c:3981 #1 0x63c4a47b in g_object_unref (_object=0x519b9e0) at ../../gobject/gobject.c:3067 #2 0x64842fb0 in ovirt_collection_refresh_from_xml (collection=0x50d4450, root_node=<optimized out>, error=0x28fb8c) at ../../govirt/ovirt-collection.c:276 #3 0x64843c49 in get_collection_xml_async_cb (proxy=0x3aebfd0, call=0x50d28a0, user_data=0x29c2ce0, error=0x28fb8c) at ../../govirt/ovirt-proxy.c:343 #4 0x64843bb2 in call_async_cb (call=0x50d28a0, error=0x0, weak_object=0x0, user_data=0x50d8680) at ../../govirt/ovirt-proxy.c:248 #5 0x00023fa7 in ?? () from C:\Program Files (x86)\VirtViewer v2.0-80\bin\librest-0.7-0.dll #6 0x051600e0 in ?? ()
Just for the record, this is the libgovirt commit that solves the issue: 7b48a957f733704f7dddd3b682111675e989666c
(In reply to Vaclav Ehrlich from comment #4) > (In reply to Yaniv Kaul from comment #2) > > Why is not filed under mingw-virt-viewer component? > > Well because if you remove ovirt part from *vv file, mingw-virt-viewer works > without segfault. But I guess you mean that portal do everything right so > I'll change the component. For sure builds 15 and 16 behave differently, and we need to find first of all why, and what version behaves correctly prior to change the component. This should be a blocker issue. The client should not crash, it is the second issue, not a blocker.
As indicated in https://bugzilla.redhat.com/show_bug.cgi?id=1274356#c6 : « This bug is happening because the are 2 storage domains in the RHEV setup, and they both have the same name ('iso'). This triggers an untested code path in libgovirt, where some memory corruption happens. This could not happen with rhev 3.5 or older as the foreign menu code was not used (if I'm not mistaken). I have no idea how likely it is that customers will have storage domains with the same names (but the same crash woulod occur with VMs with the same names too). However, given that the fix is small, better be safe than sorry and make a zstream update for that. While we should make sure the zstream is released around the same time as 3.6 GA, I'm not sure this should be marked as a blocker as it only happens on some setups. »
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. https://rhn.redhat.com/errata/RHEA-2016-0377.html