Bug 804142 - Reading XML-Description of a bridge with a vlan device creates a segfault
Reading XML-Description of a bridge with a vlan device creates a segfault
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Laine Stump
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-16 11:58 EDT by Hendrik Schwartke
Modified: 2012-07-13 14:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Ubuntu precise
Last Closed: 2012-07-13 14:46:15 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)

  None (edit)
Description Hendrik Schwartke 2012-03-16 11:58:43 EDT
Description of problem:

virsh iface-define bridge-with-vlan.xml
virsh iface-start br-test
virsh iface-dumpxml br-test
--> libvirtd deamon crashes with a segmentation fault

bridge-with-vlan.xml:
<interface type='bridge' name='br-test'>
  <start mode='onboot'/>
  <bridge stp='off' delay='0'>
    <interface type='vlan' name='eth0.666'>
      <vlan tag='666'>
        <interface name='eth0'/>
      </vlan>
    </interface>
  </bridge>
</interface>

libvirt commit used is 0ba86207bc0b76830f58c5d4a064277496cdf70d.
version of netcf: 0.1.9

ldd libvirtd:
        linux-vdso.so.1 =>  (0x00007fffb31ff000)
        libvirt-qemu.so.0 => /usr/local/lib/libvirt-qemu.so.0 (0x00007f006729b000)
        libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f0066fdf000)
        libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f0066c83000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f0066a64000)
        libdevmapper.so.1.02.1 => /lib/libdevmapper.so.1.02.1 (0x00007f0066841000)
        libnetcf.so.1 => /usr/lib/libnetcf.so.1 (0x00007f006662e000)
        libvirt.so.0 => /usr/local/lib/libvirt.so.0 (0x00007f00661cf000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0065fb2000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0065bf6000)
        libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f00659e5000)
        libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f0065767000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f006554f000)
        libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f006533d000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0065139000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0064e3e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f00674b0000)
        libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x00007f0064c31000)
        libaugeas.so.0 => /usr/lib/libaugeas.so.0 (0x00007f00649ed000)
        libexslt.so.0 => /usr/lib/x86_64-linux-gnu/libexslt.so.0 (0x00007f00647d7000)
        libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x00007f006459c000)
        libnl-route-3.so.200 => /usr/lib/libnl-route-3.so.200 (0x00007f0064357000)
        libnl-3.so.200 => /lib/libnl-3.so.200 (0x00007f006413e000)
        libyajl.so.1 => /usr/lib/x86_64-linux-gnu/libyajl.so.1 (0x00007f0063f36000)
        libnl.so.1 => /usr/lib/x86_64-linux-gnu/libnl.so.1 (0x00007f0063ce5000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0063adc000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f00638d9000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f00636d4000)
        libfa.so.1 => /usr/lib/libfa.so.1 (0x00007f00634c3000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f00632ad000)
Comment 1 Laine Stump 2012-03-18 04:44:44 EDT
This is not the case on Fedora 16 with netcf-0.1.9-1.fc16.x86_64 and libvirt build from git (post-0.9.10). I did a direct cut/paste of your example.

Can you provide a backtrace of the crash? (before triggering the crash, run gdb and attach libvirtd's pid. after the crash is triggered, enter the command "bt").

What OS/version are you running, and what exact build of netcf?
Comment 2 Hendrik Schwartke 2012-03-19 05:16:23 EDT
I'm using Ubuntu precise with
libnetcf1-dbg: 0.1.9-2ubuntu3,
libnl-3-200-dbg: 3.2.3-2ubuntu1, 
libnl-genl-3-200: 3.2.3-2ubuntu1,
libnl-nf-3-200: 3.2.3-2ubuntu1,
libnl-route-3-200: 3.2.3-2ubuntu1,
libnl1: 1.1-7

To make the backtrace more readable I installed the debug version of libnetcf1 and libnl-3-200. Now libvirtd throws a SIGABORT and libnl writes the follwing error message:
APPLICATION BUG: /build/buildd/libnl3-3.2.3/./lib/route/link/vlan.c:382:rtnl_link_vlan_get_id: Link is not a vlan link. set type "vlan" first.
libvirtd: /build/buildd/libnl3-3.2.3/./lib/route/link/vlan.c:382: rtnl_link_vlan_get_id: Assertion `0' failed.

Backtrace:
#0  0x00007ffff656c445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff656fbab in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff656510e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff65651b2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff4cbbf86 in rtnl_link_vlan_get_id (link=<optimized out>) at /build/buildd/libnl3-3.2.3/./lib/route/link/vlan.c:382
#5  0x00007ffff6f74dcf in add_vlan_info_cb (obj=0x7fffe8045950, arg=0x7ffff2355930) at dutil_linux.c:1067
#6  0x00007ffff4a8b637 in nl_cache_foreach_filter (cache=0x7fffe4000c00, filter=0x7fffe806f920, cb=0x7ffff6f74ce0 <add_vlan_info_cb>, arg=0x7ffff2355930)
    at /build/buildd/libnl3-3.2.3/./lib/cache.c:957
#7  0x00007ffff6f748eb in add_vlan_info (root=0x7fffe8048e30, doc=0x7fffe80331c0, ifindex=5, ncf=0x7fffe40012b0, ifname=<optimized out>) at dutil_linux.c:1102
#8  add_type_specific_info (ncf=0x7fffe40012b0, ifname=<optimized out>, ifindex=5, doc=0x7fffe80331c0, root=0x7fffe8048e30) at dutil_linux.c:1244
#9  0x00007ffff6f74b80 in add_bridge_info (root=<optimized out>, doc=0x7fffe80331c0, ifname=<optimized out>, ncf=0x7fffe40012b0, ifindex=<optimized out>) at dutil_linux.c:1144
#10 add_type_specific_info (ncf=0x7fffe40012b0, ifname=<optimized out>, ifindex=<optimized out>, doc=0x7fffe80331c0, root=<optimized out>) at dutil_linux.c:1241
#11 0x00007ffff6f75276 in add_state_to_xml_doc (nif=0x7fffe80490b0, doc=0x7fffe80331c0) at dutil_linux.c:1283
#12 0x00007ffff6f76a7f in drv_xml_state (nif=0x7fffe80490b0) at drv_debian.c:745
#13 0x00000000004de7aa in interfaceGetXMLDesc (ifinfo=<optimized out>, flags=<optimized out>) at interface/netcf_driver.c:360
#14 0x00007ffff6bf2996 in virInterfaceGetXMLDesc (iface=0x7fffe806e3c0, flags=0) at libvirt.c:10837
#15 0x000000000042f847 in remoteDispatchInterfaceGetXMLDesc (ret=0x7fffe806d830, args=0x7fffe811bf50, rerr=0x7ffff2355cd0, client=<optimized out>, server=<optimized out>, msg=<optimized out>)
    at remote_dispatch.h:7210
#16 remoteDispatchInterfaceGetXMLDescHelper (server=<optimized out>, client=<optimized out>, msg=<optimized out>, rerr=0x7ffff2355cd0, args=0x7fffe811bf50, ret=0x7fffe806d830)
    at remote_dispatch.h:7186
#17 0x00007ffff6c3a045 in virNetServerProgramDispatchCall (msg=0x7aa150, client=0x765c30, server=0x74e950, prog=0x769f00) at rpc/virnetserverprogram.c:416
#18 virNetServerProgramDispatch (prog=0x769f00, server=0x74e950, client=0x765c30, msg=0x7aa150) at rpc/virnetserverprogram.c:289
#19 0x00007ffff6c36301 in virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x74e950) at rpc/virnetserver.c:164
#20 0x00007ffff6b6db4e in virThreadPoolWorker (opaque=<optimized out>) at util/threadpool.c:144
#21 0x00007ffff6b6d1f6 in virThreadHelper (data=<optimized out>) at util/threads-pthread.c:161
#22 0x00007ffff68f8e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#23 0x00007ffff662674d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#24 0x0000000000000000 in ?? ()

Furthermore I forgot to mention that libvirtd writes the following error message right after startup:
error : ebiptablesDriverInit:4111 : essential tools to support ip(6)tables firewalls could not be located
Comment 3 Hendrik Schwartke 2012-03-19 06:14:38 EDT
I can confirm that under fedora 16 no segfault or abort is thrown.
But there seems to be another bug: Bug 804575.
Comment 4 Hendrik Schwartke 2012-03-19 11:28:40 EDT
Using the current version of netcf (commit d340f2dfcd6461c9743dccdabe3b610f5fbc8fe8) the bug doesn't occur!
Comment 5 Laine Stump 2012-07-13 14:46:15 EDT
The crash in this bug occurred while running code built from an early version of the netcf port to ubuntu, and according to the reporter the problem no longer occurs, so I'm closing it.

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