Bug 503254 - virsh dumpxml with segmentation fault on XEN 3.4.0
virsh dumpxml with segmentation fault on XEN 3.4.0
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
low Severity high
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-29 21:07 EDT by Sascha Guenther
Modified: 2010-03-16 13:20 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-26 14:22:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
libvirt-0.6.4_xen-3.4.0_vfb_sexpr.patch (799 bytes, patch)
2009-05-31 08:53 EDT, Sascha Guenther
no flags Details | Diff

  None (edit)
Description Sascha Guenther 2009-05-29 21:07:01 EDT
Description of problem:

A segmentation fault happens whenever I use "virsh dumpxml <domid>" or "virsh vncdisplay <domid>".
But only if "vfb = ['type=vnc']" is defined on the DomUs. 


Version-Release number of selected component (if applicable):

RPM packages from the default sources which are located on:

http://www.gitco.de/repo/xen3.4.0/

xen-3.4.0-2.el5.x86_64.rpm
xen-libs-3.4.0-2.el5.x86_64.rpm
ibvirt-0.6.4-1.el5.x86_64.rpm
libvirt-python-0.6.4-1.el5.x86_64.rpm

How reproducible:
If defined "vfb = ['type=vnc']"

virsh dumpxml <domid>
virsh vncdisplay <domid>


Steps to Reproduce:
1.
2.
3.
  
Actual results:

root@vh0002 xentest]# virsh list
 Id Name                 State
----------------------------------
  0 Domain-0             running
  5 vml0011              running

[root@vh0002 xentest]# grep vfb vml0011
vfb = [ 'type=vnc' ]
[root@vh0002 xentest]# gdb --args virsh dumpxml vml0011
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) run
Starting program: /usr/bin/virsh dumpxml vml0011
[Thread debugging using libthread_db enabled]
[New Thread 0x2b6e579278e0 (LWP 5115)]
[New Thread 0x418be940 (LWP 5119)]

Program received signal SIGSEGV, Segmentation fault.
0x000000363f6787d2 in strcmp () from /lib64/libc.so.6
(gdb) bt
#0  0x000000363f6787d2 in strcmp () from /lib64/libc.so.6
#1  0x00002b6e5746af47 in virEnumFromString (types=0x2b6e57704140, ntypes=4, type=0x0) at util.c:1598
#2  0x00002b6e574b8ceb in xenDaemonParseSxprGraphicsNew (conn=0x127b77d0, def=0x127d8730, root=<value optimized out>) at xend_internal.c:2087
#3  0x00002b6e574bc83b in xenDaemonParseSxpr (conn=0x127b77d0, root=0x127d8710, xendConfigVersion=4, cpus=0x0) at xend_internal.c:2458
#4  0x00002b6e574bd2e9 in xenDaemonDomainFetch (conn=0x127b77d0, domid=<value optimized out>, name=<value optimized out>, cpus=0x0) at xend_internal.c:3378
#5  0x00002b6e574bda95 in xenDaemonDomainDumpXML (domain=0x127d8610, flags=0, cpus=0x5e4e1 <Address 0x5e4e1 out of bounds>) at xend_internal.c:3422
#6  0x00002b6e574b40c2 in xenUnifiedDomainDumpXML (dom=0x127d8610, flags=0) at xen_unified.c:1034
#7  0x00002b6e5747be2a in virDomainGetXMLDesc (domain=0x127d8610, flags=0) at libvirt.c:2723
#8  0x000000000040871c in cmdDumpXML (ctl=<value optimized out>, cmd=0x127b1590) at virsh.c:2200
#9  0x000000000041114c in vshCommandRun (ctl=0x7fff53666fe0, cmd=0x127b1590) at virsh.c:6705
#10 0x0000000000411a34 in main (argc=1, argv=0x7fff53667148) at virsh.c:7658
(gdb) 

Expected results:


Additional info:
Comment 1 Mike Brady 2009-05-29 23:33:39 EDT
Same problem here.  Problem started occurring after upgrading from Xen 3.3.1 to 3.4.0.
Comment 2 Daniel Veillard 2009-05-30 11:33:39 EDT
hum can you provide the full sexpr for the domain, IIRC
xm list --long domain_name
should show it.
With it it should be possible to debug the problem easilly (i.e.
without installing the version.

The cause of the segfault is that
  tmp = sexpr_node(node, "device/vfb/type");
returns NULL, and that's not checked, but we will have to find
what is going on in the sexpr in that new version.

IMHO virEnumFromString should also check against NULL, but it's
a different story.

Daniel
Comment 3 Sascha Guenther 2009-05-30 11:57:24 EDT
Hi Daniel, 

thanks for this information!


Here is the output as requested:

#################

(domain
    (domid 2)
    (on_crash destroy)
    (uuid d987d7b8-9464-2418-9323-9ccddce22f50)
    (bootloader_args )
    (vcpus 1)
    (name vml0011)
    (on_poweroff destroy)
    (on_reboot destroy)
    (cpus (()))
    (bootloader )
    (maxmem 512)
    (memory 512)
    (shadow_memory 0)
    (features )
    (on_xend_start ignore)
    (on_xend_stop ignore)
    (start_time 1243698892.29)
    (cpu_time 1.574106778)
    (online_vcpus 1)
    (image
        (linux
            (kernel /var/lib/xen/images/xen/vmlinuz)
            (ramdisk /var/lib/xen/images/xen/initrd.img)
            (args
                'text vnc headless ks=http://10.255.255.1/ftp/pub/os/vml0010.cfg'
            )
            (videoram 4)
            (device_model /usr/lib64/xen/bin/qemu-dm)
            (notes
                (FEATURES
                    'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel'
                )
                (VIRT_BASE 18446744071562067968)
                (GUEST_VERSION 2.6)
                (PADDR_OFFSET 18446744071562067968)
                (GUEST_OS linux)
                (HYPERCALL_PAGE 18446744071564189696)
                (LOADER generic)
                (ENTRY 18446744071564165120)
                (XEN_VERSION xen-3.0)
            )
        )
    )
    (status 2)
    (state -b----)
    (store_mfn 804259)
    (console_mfn 804258)
    (device
        (vif
            (bridge eth0)
            (mac 00:16:3E:F7:1A:8B)
            (script /etc/xen/scripts/vif-bridge)
            (uuid 4df93125-7c3b-846f-f84e-7522dd9e6d9f)
            (backend 0)
        )
    )
    (device (vkbd (backend 0)))
    (device
        (vfb
            (uuid 4acac909-349c-a943-156f-63ab7dd2d17a)
            (location 0.0.0.0:5900)
            (vnc 1)
            (display localhost:10.0)
            (xauthority /root/.Xauthority)
        )
    )
    (device
        (console
            (protocol vt100)
            (location 2)
            (uuid c91224d0-3c7b-a6b1-0f37-c191b76826c6)
        )
    )
    (device
        (tap
            (protocol x86_64-abi)
            (uuid d22bd606-e0c5-6476-194a-f61ae1a45faf)
            (bootable 1)
            (dev xvda:disk)
            (uname tap:aio:/xentest/1.img)
            (mode w)
            (backend 0)
            (bootable 1)
            (VDI )
        )
    )
)

#################


Cheers,
Sascha
Comment 4 Sascha Guenther 2009-05-30 12:09:19 EDT
I checked it on xen 3.3.1 and it was = "(type vnc)"
And on xen 3.4.0 it is = "(vnc 1)"

Sascha
Comment 5 Sascha Guenther 2009-05-31 08:53:10 EDT
Created attachment 346007 [details]
libvirt-0.6.4_xen-3.4.0_vfb_sexpr.patch
Comment 6 Sascha Guenther 2009-05-31 09:02:27 EDT
Hi Daniel, 

with your info, I could create a quick and dirty patch. 
Now, it works for me. Also a "virsh create just_dumped.xml" with a defined vnc!

[root@vh0004 tmp]# xm in | egrep 'release|machine|xen_major|xen_minor|xen_extra'
release                : 2.6.18-128.1.10.el5xen
machine                : x86_64
xen_major              : 3
xen_minor              : 4
xen_extra              : .0

[root@vh0004 tmp]# virsh dumpxml sl-vm0005
<domain type='xen' id='2'>
  <name>sl-vm0005</name>
  <uuid>b11d3dc7-9eab-2f61-f975-c331dfeb9c35</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>2</vcpu>
  <bootloader>/usr/bin/pygrub</bootloader>
  <bootloader_args>-q</bootloader_args>
  <os>
    <type>linux</type>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/xen/sl-vm0005/disks/hda.img'/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/xen/sl-vm0005/disks/hdc.img'/>
      <target dev='xvdc' bus='xen'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:98:0e:c6'/>
      <source bridge='br1'/>
      <script path='/etc/xen/scripts/vif-bridge'/>
      <target dev='vif2.0'/>
    </interface>
    <console type='pty' tty='/dev/pts/2'>
      <source path='/dev/pts/2'/>
      <target port='0'/>
    </console>
    <input type='mouse' bus='xen'/>
    <graphics type='vnc' port='5900' autoport='no'/>
  </devices>
</domain>

[root@vh0004 tmp]# virsh dumpxml sl-vm0005 > /tmp/just_dumped.xml

[root@vh0004 tmp]# virsh create /tmp/just_dumped.xml
Domain sl-vm0005 created from /tmp/just_dumped.xml


[root@vh0004 tmp]# virsh list
 Id Name                 State
----------------------------------
  0 Domain-0             running
  1 sl-vm0001            idle
  4 sl-vm0004            idle
  5 sl-vm0005            idle

[root@vh0004 tmp]# xm li
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   768     4     r-----    128.0
sl-vm0001                                    1   256     2     -b----      5.9
sl-vm0004                                    4  1024     1     -b----     29.6
sl-vm0005                                    5  1024     2     -b----      4.3

But I wondered with the "virsh create /tmp/just_dumped.xml",
because I didn't change "xenDaemonFormatSxprGraphicsNew".

Another things is, that the domains are in "idle" state, but this is a different issue!

Cheers,
Sascha
Comment 7 Daniel Veillard 2009-06-26 14:22:51 EDT
Okay, I applied a patch upstream based on that one with a couple of
tweaks,

  thanks Sascha !

Daniel

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