[Pkg-libvirt-maintainers] Bug#883785: Bug#883785: libvirtd 3.10 segfault when starting a VM

[Guido Günther]

control: reassign -1 libvirtd
control: found 3.9.0-1
control: retitle -1 libvirtd crashes when starting a vm with IDE cdrom
control: forcemerge -1 881293

Hi,
On Thu, Dec 07, 2017 at 03:38:24PM +0100, Pascal Obry wrote:
> 
> Package: libvirt
> Version: 3.10
> Severity: grave
> 
> With libvirt version 3.10 I cannot start a VM. Reverting to 3.0
> (Debian/stable) all is fine. This was initially found in GNOME-Boxes
> but I have been able to reproduce on the command line using virsh.
> 
> Note also that I had the same issue with 3.9.
> 
> On one console:
> 
> $ LIBVIRT_DEBUG=1 gdb /usr/sbin/libvirtd
> 
> On a second console, I tried to start the VM:
> 
> $ virsh start boxes-winxp
> 
> Then I got this exception from libvirtd:
> 
> Thread 5 "libvirtd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7febad4a5700 (LWP 7867)]
> 0x00007feb94b109c8 in virStorageFileReportBrokenChain ()
>    from /usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
> (gdb) bt
> #0  0x00007feb94b109c8 in virStorageFileReportBrokenChain ()
>    from /usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
> #1  0x00007feb7d266da3 in qemuDomainDetermineDiskChain ()
>    from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
> #2  0x00007feb7d28eec2 in qemuProcessPrepareHost ()
>    from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
> #3  0x00007feb7d294b71 in qemuProcessStart ()
>    from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
> #4  0x00007feb7d2f5201 in ?? ()
>    from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
> #5  0x00007feb7d2f58e6 in ?? ()
>    from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
> #6  0x00007febb9e5e077 in virDomainCreate (domain=0x7feb980008c0)
>     at ../../../src/libvirt-domain.c:6531
> #7  0x000056190ba2ed9c in ?? ()
> #8  0x00007febb9ec697c in virNetServerProgramDispatchCall (msg=0x56190d9e7590, 
>     client=0x56190d9e6fb0, server=0x56190d9d00f0, prog=0x56190d9e4f40)
>     at ../../../src/rpc/virnetserverprogram.c:437
> #9  virNetServerProgramDispatch (prog=0x56190d9e4f40, server=0x56190d9d00f0, 
>     client=0x56190d9e6fb0, msg=0x56190d9e7590)
>     at ../../../src/rpc/virnetserverprogram.c:307
> #10 0x000056190ba3e988 in ?? ()
> #11 0x00007febb9da1c01 in virThreadPoolWorker (
>     opaque=opaque at entry=0x56190d9ce9f0)
>     at ../../../src/util/virthreadpool.c:167
> #12 0x00007febb9da0f78 in virThreadHelper (data=<optimized out>)
>     at ../../../src/util/virthread.c:206
> #13 0x00007febb68b0519 in start_thread (arg=0x7febad4a5700)
>     at pthread_create.c:456
> #14 0x00007febb65f2a5f in clone ()
>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
> (gdb) 
> 
> I noticed that running with 3.0 I had a message saying that /dev/sr0 is
> not accessible. And indeed I do not have a CDROM on this machine. The
> .xml were migrated from a machine with a CDROM to this new one.
> 
> Removing:
> 
>     <disk type='block' device='cdrom'>
>       <driver name='qemu' type='raw'/>
>       <source dev='/dev/sr0' startupPolicy='optional'/>
>       <target dev='hdc' bus='ide'/>
>       <readonly/>
>       <address type='drive' controller='0' bus='1' target='0' unit='0'/>
>     </disk>
> 
> Seems to fix the issue. Yet, libvirt should not crash on this. And the
> backtrace makes sense with this fix BTW.

Yept. Should not crash. Looks similar to another issue I did not get
around to look at.

Cheers,
 -- Guido