Same problem here.  Problem started occurring after upgrading from Xen 3.3.1 to 3.4.0.

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

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

I checked it on xen 3.3.1 and it was = "(type vnc)"
And on xen 3.4.0 it is = "(vnc 1)"

Sascha

Created attachment 346007 [details]
libvirt-0.6.4_xen-3.4.0_vfb_sexpr.patch

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

Okay, I applied a patch upstream based on that one with a couple of
tweaks,

  thanks Sascha !

Daniel