[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]