[libvirt] [PATCH 00/16] snapshot refactoring (incremental backup saga)

Daniel P. Berrangé berrange at redhat.com
Fri Mar 22 11:26:39 UTC 2019


On Fri, Mar 22, 2019 at 07:10:05AM -0400, John Ferlan wrote:
> 
> 
> On 3/22/19 7:04 AM, Andrea Bolognani wrote:
> > On Fri, 2019-03-22 at 06:50 -0400, John Ferlan wrote:
> >> On 3/22/19 4:46 AM, Andrea Bolognani wrote:
> >>> This causes libvirtd to crash at startup on my machine.
> >>>
> >>> Have a backtrace:
> >>>
> >>>   Thread 19 (Thread 0x7fffaa4e0700 (LWP 31651)):
> >>>   #0  0x00007ffff72ecd31 in open64 () from /lib64/libc.so.6
> >>>   #1  0x00007ffff727d3f6 in _IO_file_open () from /lib64/libc.so.6
> >>>   #2  0x00007ffff727d5ad in __GI__IO_file_fopen () from /lib64/libc.so.6
> >>>   #3  0x00007ffff727132d in __fopen_internal () from /lib64/libc.so.6
> >>>   #4  0x00007ffff71199d8 in ?? () from /lib64/libudev.so.1
> >>>   #5  0x00007ffff71146dd in ?? () from /lib64/libudev.so.1
> >>>   #6  0x00007ffff71173ed in ?? () from /lib64/libudev.so.1
> >>>   #7  0x00007ffff71179d9 in ?? () from /lib64/libudev.so.1
> >>>   #8  0x00007ffff710be77 in udev_device_get_property_value () from /lib64/libudev.so.1
> >>>   #9  0x00007fffc2e8a3ef in udevGetDeviceProperty (udev_device=udev_device at entry=0x7fff900606e0, property_key=property_key at entry=0x7fffc2ea3504 "DRIVER") at node_device/node_device_udev.c:140
> >>>   #10 0x00007fffc2e8a459 in udevGetStringProperty (udev_device=udev_device at entry=0x7fff900606e0, property_key=property_key at entry=0x7fffc2ea3504 "DRIVER", value=0x7fff900f98d8) at node_device/node_device_udev.c:154
> >>>   #11 0x00007fffc2e8b3ad in udevAddOneDevice (device=device at entry=0x7fff900606e0) at node_device/node_device_udev.c:1369
> >>>   #12 0x00007fffc2e8d27e in udevProcessDeviceListEntry (list_entry=0x7fff9004f350, udev=0x7fff98120f00) at node_device/node_device_udev.c:1435
> >>>   #13 udevEnumerateDevices (udev=0x7fff98120f00) at node_device/node_device_udev.c:1489
> >>>   #14 nodeStateInitializeEnumerate (opaque=0x7fff98120f00) at node_device/node_device_udev.c:1798
> >>>   #15 0x00007ffff7c5a2c2 in virThreadHelper (data=<optimized out>) at util/virthread.c:206
> >>>   #16 0x00007ffff740d58e in start_thread () from /lib64/libpthread.so.0
> >>>   #17 0x00007ffff72fc6a3 in clone () from /lib64/libc.so.6
> >>
> >> Very strange - I don't recall the patches touching any of the
> >> virnodedeviceobj* code. Is it possible to bisect to something after the
> >> below?
> >>
> >> Although there were changes by Nikolay right at the top of tree that
> >> did... Can you go back to top, revert Nikolay's changes and see if that
> >> does it?  You will need Michal's change to virDomainMomentAssignDef.
> > 
> > Michal's patch seems to do the trick: I built from 5e752513d802
> > and the daemon starts fine even when I have guests with snapshots.
> > 
> 
> Great... That was my first instinct, but would have expected to see this
> thread causing the issue not the udev one:

The stack trace isn't blaming the udev one. The udev thread is merely the
most recent, so it appears first.  The details of which thread caused
the crash were not included when stack trace was copied from gdb into
this mail thread!

> 
>   Thread 17 (Thread 0x7fffab4e2700 (LWP 31607)):
>   #0  0x00007ffff7cc1c85 in virDomainMomentAssignDef
> (moments=0x7fff981af8a0, def=def at entry=0x7fff98227870) at
> conf/virdomainmomentobjlist.c:230
> 
> gotta go check the coffee pot - I hope it wasn't decaf this morning!


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list