Re: [libvirt] [PATCH 0/8] Various KVM PCI device assignment improvements
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