libvirtd crashed with SIGSEGV in xmlHashLookup3__internal_alias()

[Sosha]

after upgrade packages...

ProblemType: Crash
DistroRelease: Ubuntu 18.04
Package: libvirt-daemon 4.0.0-1ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-25.29-generic 4.13.13
Uname: Linux 4.13.0-25-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.8-0ubuntu8
Architecture: amd64
Date: Mon Feb 5 04:19:29 2018
ExecutablePath: /usr/sbin/libvirtd
InstallationDate: Installed on 2017-09-02 (156 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
ProcAttrCurrent: /usr/sbin/libvirtd (enforce)
ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.13.0-25-generic.efi.signed root=UUID=a5d262b4-1b0f-4856-9935-f6a7f6d6d406 ro quiet splash vt.handoff=7
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
SegvAnalysis:
 Segfault happened at: 0x7ff92a1ee4b5 <xmlHashLookup+149>: mov 0x28(%rbx),%eax
 PC (0x7ff92a1ee4b5) ok
 source "0x28(%rbx)" (0xdc9b6a9060306869) not located in a known VMA region (needed readable region)!
 destination "%eax" ok
 Stack memory exhausted (SP below stack segment)
SegvReason: reading unknown VMA
Signal: 11
SourcePackage: libvirt
StacktraceTop:
 xmlHashLookup () from /usr/lib/x86_64-linux-gnu/libxml2.so.2
 ?? () from /usr/lib/x86_64-linux-gnu/libxml2.so.2
 ?? () from /usr/lib/x86_64-linux-gnu/libxml2.so.2
 ?? () from /usr/lib/x86_64-linux-gnu/libxml2.so.2
 ?? () from /usr/lib/x86_64-linux-gnu/libxml2.so.2
Title: libvirtd crashed with SIGSEGV in xmlHashLookup()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

[Apport retracing service (apport)]

StacktraceTop:
 xmlHashLookup3__internal_alias (name3=0x0, name2=0x0, name=name@entry=0x7ff8c4013030 "http://www.w3.org/2001/XMLSchema-datatypes", table=0x7ff8c4009f00) at ../../hash.c:765
 xmlHashLookup__internal_alias (table=0x7ff8c4009f00, name=name@entry=0x7ff8c4013030 "http://www.w3.org/2001/XMLSchema-datatypes") at ../../hash.c:448
 xmlRelaxNGParseData (node=0x7ff8c403a370, ctxt=0x7ff8c4008c40) at ../../relaxng.c:3648
 xmlRelaxNGParsePattern (ctxt=ctxt@entry=0x7ff8c4008c40, node=node@entry=0x7ff8c403a370) at ../../relaxng.c:4961
 xmlRelaxNGParsePatterns (ctxt=ctxt@entry=0x7ff8c4008c40, nodes=0x7ff8c403a370, group=group@entry=0) at ../../relaxng.c:5539

[Christian Ehrhardt  (paelzer)]

Hi Sosha,
the crash itself is in libxml2 so I add a bug task for that.

From the libvirt POV this seems to be in a stage where it initializes its state drivers.
virStateInitialize iterates on drivers and calls stateInitialize of the respective backend.

I can't see from your trace which that is, but I assume this triggers right when you start libvirtd?
If so did you register special backends?
The following is the list of drivers with such a function

0 bhyve_driver.c 1753 .stateInitialize = bhyveStateInitialize,
2 interface_backend_netcf.c 1139 .stateInitialize = netcfStateInitialize,
3 interface_backend_udev.c 1211 .stateInitialize = udevStateInitialize,
4 libxl_driver.c 6594 .stateInitialize = libxlStateInitialize,
5 lxc_driver.c 5590 .stateInitialize = lxcStateInitialize,
6 bridge_driver.c 4272 .stateInitialize = networkStateInitialize,
7 node_device_hal.c 778 .stateInitialize = nodeStateInitialize,
8 node_device_udev.c 2070 .stateInitialize = nodeStateInitialize,
9 nwfilter_driver.c 640 .stateInitialize = nwfilterStateInitialize,
a qemu_driver.c 21355 .stateInitialize = qemuStateInitialize,
b remote_driver.c 8648 .stateInitialize = remoteStateInitialize,
c secret_driver.c 578 .stateInitialize = secretStateInitialize,
d storage_driver.c 2743 .stateInitialize = storageStateInitialize,
0 uml_driver.c 3020 .stateInitialize = umlStateInitialize,
1 vz_driver.c 4171 .stateInitialize = vzStateInitialize,
2 xen_driver.c 269 .stateInitialize = xenUnifiedStateInitialize,

Since it has netcf entries down the stack trace I can only assume it is the init of netcf.
That would be in netcfStateInitialize

There is calls ncf_init and the lib also has libxml2 bindings.
I fail to derive more from the stack trace as-is, but that already meand we should also add a task for netcf.

I wonder:
1. is this reproducible on e.g. every restart of libvirtd?
2. do you have any non-default network configuration on the system or in libvirt that might be what we would need to reproduce that?