Bug 1273977 - Remote-viewer crash after login to VM
Remote-viewer crash after login to VM
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer (Show other bugs)
3.6.0
Unspecified Unspecified
unspecified Severity urgent
: ovirt-3.6.1
: 3.6.1
Assigned To: Default Assignee for SPICE Bugs
SPICE QE bug list
:
Depends On:
Blocks: 1274355 1274356
  Show dependency treegraph
 
Reported: 2015-10-21 12:06 EDT by Vaclav Ehrlich
Modified: 2016-03-09 15:12 EST (History)
17 users (show)

See Also:
Fixed In Version: mingw-libgovirt-0.3.3-2.el7ev mingw-virt-viewer-2.0-6.el7ev rhevm-spice-client-3.6-4
Doc Type: Bug Fix
Doc Text:
Improved memory handling so that applications using the libgovirt library no longer crash when multiple ISO domains with the same name are found in REST requests. Applications using libgovirt no longer crash due to memory corruption.
Story Points: ---
Clone Of:
: 1274355 1274356 (view as bug list)
Environment:
Last Closed: 2016-03-09 15:12:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Spice
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
--debug --spice-debug run (24.24 KB, text/plain)
2015-10-22 07:29 EDT, Andrei Stepanov
no flags Details

  None (edit)
Description Vaclav Ehrlich 2015-10-21 12:06:12 EDT
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 ?? ()
Comment 1 Vaclav Ehrlich 2015-10-22 04:41:37 EDT
Just forgot mention that this started after update RHEVM from build 15 to 16
Comment 2 Yaniv Kaul 2015-10-22 04:48:31 EDT
Why is not filed under mingw-virt-viewer component?
Comment 3 Yaniv Kaul 2015-10-22 04:49:58 EDT
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.
Comment 4 Vaclav Ehrlich 2015-10-22 06:15:08 EDT
(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.
Comment 7 Andrei Stepanov 2015-10-22 07:29 EDT
Created attachment 1085475 [details]
--debug --spice-debug run
Comment 8 Fabiano Fidêncio 2015-10-22 08:03:14 EDT
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 ?? ()
Comment 9 Fabiano Fidêncio 2015-10-22 09:30:18 EDT
Just for the record, this is the libgovirt commit that solves the issue:
7b48a957f733704f7dddd3b682111675e989666c
Comment 12 David Blechter 2016-01-04 13:06:04 EST
(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.
Comment 13 Christophe Fergeau 2016-01-07 09:07:18 EST
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. »
Comment 16 errata-xmlrpc 2016-03-09 15:12:01 EST
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

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