Ubuntu
libvirt package

libvirtd crashed with SIGSEGV in xmlHashLookup3__internal_alias()

Bug #1747394 reported by Sosha on 2018-02-05

10

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	libvirt (Ubuntu)	Incomplete	Medium	Unassigned
	libxml2 (Ubuntu)	New	Undecided	Unassigned
	netcf (Ubuntu)	New	Undecided	Unassigned

Bug Description

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:

Tags:

Revision history for this message

Sosha (soshaw) wrote on 2018-02-05:

#1

Dependencies.txt Edit (6.9 KiB, text/plain; charset="utf-8")
Disassembly.txt Edit (1.1 KiB, text/plain; charset="utf-8")
JournalErrors.txt Edit (119.5 KiB, text/plain; charset="utf-8")
KernLog.txt Edit (9.3 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.2 KiB, text/plain; charset="utf-8")
ProcMaps.txt Edit (70.2 KiB, text/plain; charset="utf-8")
ProcStatus.txt Edit (1.2 KiB, text/plain; charset="utf-8")
Registers.txt Edit (972 bytes, text/plain; charset="utf-8")
RelatedPackageVersions.txt Edit (164 bytes, text/plain; charset="utf-8")
Stacktrace.txt Edit (2.1 KiB, text/plain; charset="utf-8")
ThreadStacktrace.txt Edit (32.1 KiB, text/plain; charset="utf-8")

information type:

Private → Public

Revision history for this message

Apport retracing service (apport) wrote on 2018-02-05:

#2

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

Revision history for this message

Apport retracing service (apport) wrote on 2018-02-05: Stacktrace.txt

#3

Stacktrace.txt Edit (5.0 KiB, text/plain)

Revision history for this message

Apport retracing service (apport) wrote on 2018-02-05: StacktraceSource.txt

#4

StacktraceSource.txt Edit (4.8 KiB, text/plain)

Revision history for this message

Apport retracing service (apport) wrote on 2018-02-05: ThreadStacktrace.txt

#5

ThreadStacktrace.txt Edit (57.5 KiB, text/plain)

Changed in libvirt (Ubuntu):
importance:	Undecided → Medium
summary:	- libvirtd crashed with SIGSEGV in xmlHashLookup() + libvirtd crashed with SIGSEGV in xmlHashLookup3__internal_alias()
tags:	removed: need-amd64-retrace

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2018-02-05:

#6

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?

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?

Changed in libvirt (Ubuntu):
status:	New → Incomplete

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.