[libvirt] [PATCH 0/8] Various KVM PCI device assignment improvements

[Mirko Raasch]

Charles Duffy schrieb:
> Mirko Raasch wrote:
>> How can i use valgrind or some other debugging options with 
>> "/etc/init.d/libvirt-bin"?
>
> This won't work for valgrind, but the gdb "attach" command will let 
> you connect to (and thus get a stack trace from) a running process.
>
> If your libvirtd has PID 12054, for instance:
>
> $ gdb /usr/sbin/libvirtd
> (gdb) attach 12054
> ...let it attach, and then cause the crash...
> (gdb) bt
> ^^ and post the output.
>
> The stack trace will be most informative if your build was done with 
> debug symbols enabled and not stripped on installation.
I think, the problem has changed:

I start libvirt with "/usr/sbin/libvirtd start" and then "virsh start 
vdr". The guest is running, but only one of both pci cards is usable.
When i shut down the guest, libvirt says nothing, but the process is 
killed. When i tray to restart libvirt, valgrind says:

libvir: QEMU error : monitor socket did not show up.: Connection refused
22:08:59.307: error : qemuReconnectDomain:315 : Failed to reconnect 
monitor for vdr: -1

==8823==
==8823== Invalid read of size 8
==8823==    at 0x420C04: qemuCheckPciHostDevice (qemu_driver.c:1337)
==8823==    by 0x4E48CA7: pciResetDevice (pci.c:606)
==8823==    by 0x4229D5: qemudShutdownVMDaemon (qemu_driver.c:1479)
==8823==    by 0x43150B: qemudStartup (qemu_driver.c:357)
==8823==    by 0x4E5E9E0: virStateInitialize (libvirt.c:768)
==8823==    by 0x413731: main (qemud.c:856)
==8823==  Address 0x38 is not stack'd, malloc'd or (recently) free'd
==8823==
==8823== Process terminating with default action of signal 11 (SIGSEGV)
==8823==  Access not within mapped region at address 0x38
==8823==    at 0x420C04: qemuCheckPciHostDevice (qemu_driver.c:1337)
==8823==    by 0x4E48CA7: pciResetDevice (pci.c:606)
==8823==    by 0x4229D5: qemudShutdownVMDaemon (qemu_driver.c:1479)
==8823==    by 0x43150B: qemudStartup (qemu_driver.c:357)
==8823==    by 0x4E5E9E0: virStateInitialize (libvirt.c:768)
==8823==    by 0x413731: main (qemud.c:856)
==8823==  If you believe this happened as a result of a stack overflow 
in your
==8823==  program's main thread (unlikely but possible), you can try to 
increase
==8823==  the size of the main thread stack using the --main-stacksize= 
flag.
==8823==  The main thread stack size used in this run was 8388608.
==8823==
==8823== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 54 from 4)
==8823== malloc/free: in use at exit: 13,597 bytes in 324 blocks.
==8823== malloc/free: 2,889 allocs, 2,565 frees, 461,799 bytes allocated.
==8823== For counts of detected errors, rerun with: -v
==8823== Use --track-origins=yes to see where uninitialised values come from
==8823== searching for pointers to 324 not-freed blocks.
==8823== checked 260,104 bytes.
==8823==
==8823== LEAK SUMMARY:
==8823==    definitely lost: 584 bytes in 22 blocks.
==8823==      possibly lost: 0 bytes in 0 blocks.
==8823==    still reachable: 13,013 bytes in 302 blocks.
==8823==         suppressed: 0 bytes in 0 blocks.
==8823== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault

Mirko