Bug 1003458

Summary: Segmentation fault when connect to the guest console
Product: [Community] Virtualization Tools Reporter: Alex Jia <ajia>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dyuan, gscrivan, gsun, jdenemar, jtomko, rbalakri
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-16 18:27:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alex Jia 2013-09-02 05:44:43 UTC
Description of problem:
Segmentation fault when using python API openConsole(None, None) to connect the guest console.


Version-Release number of selected component (if applicable):
# rpm -q libvirt libvirt-python kernel
libvirt-1.1.1-3.el7.x86_64
libvirt-python-1.1.1-3.el7.x86_64
kernel-3.10.0-0.rc7.64.el7.x86_64


How reproducible:
always

Steps to Reproduce:

>>> import libvirt
>>> con = libvirt.open(None)
>>> dom = con.listAllDomains()[0]
>>> dom.XMLDesc()
"<domain type='qemu'>\n  <name>hello</name>\n  <uuid>9403d7cb-6961-6979-0ecf-7be3d75298f9</uuid>\n  <memory unit='KiB'>1048576</memory>\n  <currentMemory unit='KiB'>1048576</currentMemory>\n  <vcpu placement='static'>1</vcpu>\n  <os>\n    <type arch='x86_64' machine='pc-1.3'>hvm</type>\n    <boot dev='hd'/>\n  </os>\n  <clock offset='utc'/>\n  <on_poweroff>destroy</on_poweroff>\n  <on_reboot>restart</on_reboot>\n  <on_crash>destroy</on_crash>\n  <devices>\n    <emulator>/usr/libexec/qemu-kvm</emulator>\n    <disk type='block' device='disk'>\n      <driver name='qemu' type='raw'/>\n      <source dev='/var/lib/libvirt/images/hello'/>\n      <target dev='hda' bus='ide'/>\n      <address type='drive' controller='0' bus='0' target='0' unit='0'/>\n    </disk>\n    <controller type='usb' index='0'>\n      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>\n    </controller>\n    <controller type='ide' index='0'>\n      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>\n    </controller>\n    <controller type='pci' index='0' model='pci-root'/>\n    <interface type='network'>\n      <mac address='52:54:00:24:2c:b3'/>\n      <source network='default'/>\n      <model type='virtio'/>\n      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>\n    </interface>\n    <memballoon model='virtio'>\n      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>\n    </memballoon>\n  </devices>\n  <seclabel type='dynamic' model='selinux' relabel='yes'/>\n</domain>\n"
>>> dom.openConsole(None, None)
Segmentation fault (core dumped)


Actual results:
Segmentation fault (core dumped).

Expected results:
Fix segmentation fault.

Additional info:

Valgrind defects memory error:

==10259== 1 errors in context 1 of 467:
==10259== Invalid write of size 8
==10259==    at 0xC0A1042: remoteDomainOpenConsole (remote_client_bodies.h:2689)
==10259==    by 0xC087FEC: virDomainOpenConsole (libvirt.c:20569)
==10259==    by 0xBD37547: libvirt_virDomainOpenConsole (libvirt.c:3668)
==10259==    by 0x4CFCCED: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4CFDC7C: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4CFC768: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4CFDC7C: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4CFDD81: PyEval_EvalCode (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4D168AE: ??? (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4D179CD: PyRun_FileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4D18B38: PyRun_SimpleFileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==10259==    by 0x4D2966E: Py_Main (in /usr/lib64/libpython2.7.so.1.0)
==10259==  Address 0x28 is not stack'd, malloc'd or (recently) free'd


It exists similar issues for openChannel(None, None) python API, I will file a separate bug if needs.

==9547== 1 errors in context 1 of 486:
==9547== Invalid write of size 8
==9547==    at 0xC4DEED2: remoteDomainOpenChannel (remote_client_bodies.h:2648)
==9547==    by 0xC4C61DC: virDomainOpenChannel (libvirt.c:20630)
==9547==    by 0xC171727: libvirt_virDomainOpenChannel (libvirt.c:1897)
==9547==    by 0x3E4D4DD250: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D4DDC8E: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D4DC282: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D4DDC8E: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D4DDD61: PyEval_EvalCode (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D4F6F49: ??? (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D4F7D41: PyRun_FileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D4F875A: PyRun_SimpleFileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==9547==    by 0x3E4D509C21: Py_Main (in /usr/lib64/libpython2.7.so.1.0)
==9547==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

Comment 1 Alex Jia 2013-09-02 05:47:33 UTC
BTW, the libvirt daemon works well without crashing.


# systemctl status  libvirtd.service
libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Mon 2013-09-02 13:46:04 HKT; 17s ago
 Main PID: 10496 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ├─ 1838 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
           └─10496 /usr/sbin/libvirtd

Sep 02 13:46:04 localhost.localdomain systemd[1]: Started Virtualization daemon.
Sep 02 13:46:06 localhost.localdomain dnsmasq[1838]: read /etc/hosts - 4 addresses
Sep 02 13:46:06 localhost.localdomain dnsmasq[1838]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Sep 02 13:46:06 localhost.localdomain dnsmasq-dhcp[1838]: read /var/lib/libvirt/dnsmasq/default.hostsfile
Sep 02 13:46:10 localhost.localdomain libvirtd[10496]: libvirt version: 1.1.1, package: 3.el7 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2013-08-30-11:06:08, x86-018.build.eng.bos.redhat.com)
Sep 02 13:46:10 localhost.localdomain libvirtd[10496]: End of file while reading data: Input/output error

# virsh list
 Id    Name                           State
----------------------------------------------------
 4     foo                            running

Comment 3 Wayne Sun 2013-09-02 06:02:02 UTC
should create stream obj first and give it to console:

stream = conn.newStream(0)
domobj.openConsole(None, stream, libvirt.VIR_DOMAIN_CONSOLE_FORCE)

anyway the crash when gave None is a problem.

Comment 4 Jiri Denemark 2013-09-02 13:28:14 UTC
This is a usage error which results in a crash of the application that used the API incorrectly. That's perfectly acceptable as the documentation says "a stream to associate with the console" should be passed. That said, it would be nice to report an error instead but it's very minor issue.

Comment 5 Giuseppe Scrivano 2014-06-16 14:53:05 UTC
seems to be fixed upstream by:

commit 6e130ddc4d06620c5567a13311542421a732e084
Author: Eric Blake <eblake>
Date:   Tue Jan 7 14:38:12 2014 -0700

    maint: improve VIR_ERR_INVALID_DOMAIN usage
    
    In datatype.c, virGetDomainSnapshot could result in the message:
    
    error: invalid domain pointer in bad domain
    
    Furthermore, while there are a few functions in libvirt.c that
    only care about a virDomainPtr without regards to the connection
    (such as virDomainGetName), most functions also require a valid
    connection.  Yet several functions were blindly dereferencing
    the conn member without checking it for validity first (such as
    virDomainOpenConsole).  Rather than try and correct all usage
    of VIR_IS_DOMAIN vs. VIR_IS_CONNECTED_DOMAIN, it is easier to
    just blindly require that a valid domain object always has a
    valid connection object (which should be true anyways, since
    every domain object holds a reference to its connection, so the
    connection will not be closed until all domain objects have
    also been closed to release their reference).
    
    After this patch, all places that validate a domain consistently
    report:
    
    error: invalid domain pointer in someFunc
    
    * src/datatypes.h (virCheckDomainReturn, virCheckDomainGoto): New
    macros.
    * src/datatypes.c (virGetDomainSnapshot): Use new macro.
    (virLibConnError): Delete unused macro.

Comment 6 Ján Tomko 2015-03-16 18:27:17 UTC
git describe: v1.2.0-250-g6e130dd contains: v1.2.1-rc1~1