Bug 816006
| Summary: | memleak in qbus | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Shaolong Hu <shu> |
| Component: | qemu-kvm-rhev | Assignee: | Markus Armbruster <armbru> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Yumei Huang <yuhuang> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.0 | CC: | areis, chayang, hhuang, jinzhao, juzhang, kraxel, michen, mkenneth, rbalakri, rpacheco, shuang, virt-maint, yuhuang |
| Target Milestone: | rc | ||
| Target Release: | 7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-11-29 07:22:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Shaolong Hu
2012-04-25 03:28:27 UTC
Created attachment 580055 [details]
valgrind log of hotplug/unplug virtio serial bus and port
Created attachment 580056 [details]
valgrind log of hotplug/unplug intel-hda
Please provide a full reproducer: exact command line in addition to all the monitor commands. If you want to go the extra mile, retest with the current version. cmd to reproduce: valgrind --tool=memcheck --leak-check=yes --log-file=valgrind.log /usr/libexec/qemu-kvm -monitor stdio -nodefconfig -hda RHEL-Server-6.3-64-virtio.qcow2 -smp 2 -m 1G -enable-kvm -chardev socket,id=channel1,path=/tmp/s1,server,nowait 1. boot guest with above cmd 2. in qemu monitor, enter cmd: (qemu) device_add intel-hda,id=audio1 (qemu) device_del audio1 (qemu) quit and (qemu) device_add virtio-serial-pci,id=virtio-serial1 (qemu) device_add virtserialport,bus=virtio-serial1.0,nr=1,chardev=channel1,name=com.redhat.rhevm.vdsm.2,id=port1 (qemu) device_del port1 (qemu) device_del virtio-serial1 (qemu) quit 3. view valgrind.log will show result in comment0. Test with the latest qemu-kvm-0.12.1.2-2.297.el6.x86_64, problem still exists. BTW: if add "-nodefaults" in cmd, memleak in comment0 won't occur, i try to use this option to reduce valgrind output, but i find can not reproduce with this option. I could use a little more help, just to make sure I'm seeing exactly what you see. First, run baseline test: same command line, but quit in the monitor right away. Then repeat all three tests with QEMU option -S. Attach the resulting six valgrind logs. Thanks in advance! Created attachment 600426 [details]
base cmd
Created attachment 600427 [details]
base cmd with -nodefaults
Created attachment 600428 [details]
base cmd plug intel-hda
Created attachment 600429 [details]
base cmd plug virtio-serial
Created attachment 600430 [details]
base cmd with -nodefaults plug intel-hda
Created attachment 600431 [details]
base cmd with -nodefaults plug virtio-serial
Here are the six combination, hope i understand what you need correctly. Looks like you ran the three test cases "no hotplug, hotplug intel-hda, hotplug virtio-serial" with and without -nodefaults. That's useful, thanks. I also asked for results with -S. I think running the three test cases with -nodefaults -S would suffice. But before you do that, let me try to pinpoint the bug with the information I already have. The code changed a lot since this bug was reported against RHEL-6. Could you please retest with current RHEL-7 code? Test with qemu-kvm-0.12.1.2-2.401.el6.x86_64: intel-hda: ==25013== 22 bytes in 1 blocks are definitely lost in loss record 121 of 535 ==25013== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==25013== by 0x1C5704: qemu_malloc (qemu-malloc.c:57) ==25013== by 0x2225B4: qbus_create_inplace (qdev.c:741) ==25013== by 0x2FD7BF: hda_codec_bus_init (intel-hda.c:42) ==25013== by 0x2FD869: intel_hda_init (intel-hda.c:1154) ==25013== by 0x19FD95: pci_qdev_init (pci.c:1528) ==25013== by 0x222BD7: qdev_init (qdev.c:284) ==25013== by 0x222FEE: qdev_device_add (qdev.c:259) ==25013== by 0x2235EA: do_device_add (qdev.c:875) ==25013== by 0x197AFF: monitor_call_handler (monitor.c:4369) ==25013== by 0x19CF8E: handle_user_command (monitor.c:4406) ==25013== by 0x19D0C6: monitor_command_cb (monitor.c:5044) virtio-serial: ==25202== 30 bytes in 1 blocks are definitely lost in loss record 128 of 538 ==25202== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==25202== by 0x1C5704: qemu_malloc (qemu-malloc.c:57) ==25202== by 0x2225B4: qbus_create_inplace (qdev.c:741) ==25202== by 0x1A910E: virtio_serial_init (virtio-serial-bus.c:952) ==25202== by 0x1A8E1B: virtio_serial_init_pci (virtio-pci.c:866) ==25202== by 0x19FD95: pci_qdev_init (pci.c:1528) ==25202== by 0x222BD7: qdev_init (qdev.c:284) ==25202== by 0x222FEE: qdev_device_add (qdev.c:259) ==25202== by 0x2235EA: do_device_add (qdev.c:875) ==25202== by 0x197AFF: monitor_call_handler (monitor.c:4369) ==25202== by 0x19CF8E: handle_user_command (monitor.c:4406) ==25202== by 0x19D0C6: monitor_command_cb (monitor.c:5044) Looks like you retested with the latest RHEL-6 bits, not the latest RHEL-7 bits I asked for. Could you try that, too? (In reply to Markus Armbruster from comment #21) > Looks like you retested with the latest RHEL-6 bits, not the latest RHEL-7 > bits I asked for. Could you try that, too? Oh sorry, here the result on RHEL7 host: 1. the intel-hda problem has gone 2. virtio serial has a little change: ==21806== 17 bytes in 1 blocks are definitely lost in loss record 512 of 1,392 ==21806== at 0x4C28409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21806== by 0x2E2E1C: malloc_and_trace (vl.c:2800) ==21806== by 0x528989E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3) ==21806== by 0x52A0BAE: g_strdup (in /usr/lib64/libglib-2.0.so.0.3600.3) ==21806== by 0x33B704: virtio_device_set_child_bus_name (virtio.c:1109) ==21806== by 0x26FD00: virtio_serial_pci_init (virtio-pci.c:1338) ==21806== by 0x2703D1: virtio_pci_init (virtio-pci.c:996) ==21806== by 0x237FBA: pci_qdev_init (pci.c:1720) ==21806== by 0x1F18D0: device_realize (qdev.c:178) ==21806== by 0x1F2E3A: device_set_realized (qdev.c:699) ==21806== by 0x2B01CD: property_set_bool (object.c:1301) ==21806== by 0x2B2AB6: object_property_set_qobject (qom-qobject.c:24) ==21806== 352 (64 direct, 288 indirect) bytes in 1 blocks are definitely lost in loss record 1,175 of 1,392 ==21806== at 0x4C28409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21806== by 0x2E2E1C: malloc_and_trace (vl.c:2800) ==21806== by 0x5289385: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==21806== by 0x52898F6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3600.3) ==21806== by 0x2B13D9: object_property_add (object.c:717) ==21806== by 0x1F28CC: qdev_property_add_static (qdev.c:651) ==21806== by 0x1F2B1C: device_initfn (qdev.c:750) ==21806== by 0x2B0298: object_init_with_type (object.c:293) ==21806== by 0x2B0298: object_init_with_type (object.c:293) ==21806== by 0x26F9BD: virtio_serial_pci_instance_init (virtio-pci.c:1375) ==21806== by 0x2B093B: object_new_with_type (object.c:413) ==21806== by 0x29D49C: qdev_device_add (qdev-monitor.c:473) on qemu-kvm-1.5.3-3.el7.x86_64 I can't reproduce this issue with latest upstream or qemu-kvm-rhev anymore. QA, can you confirm this? I think we can close this BZ if you can. (In reply to Markus Armbruster from comment #28) > I can't reproduce this issue with latest upstream or qemu-kvm-rhev anymore. > QA, can you confirm this? I think we can close this BZ if you can. The bug was originally opened against qemu-kvm, but we don't care about this small memleak in downstream base RHEL, we can fix it upstream and wait for a rebase. So I'm changing the component to qemu-kvm-rehv. If we can't reproduce it anymore, then let's close it as CURRENTRELEASE. QE tried with qemu-kvm-rhev-2.10.0-9.el7, and can't reproduce with or without '-nodefaults'. No "qbus" or "qdev_device_add" showed in valgrind log. Thank you! Closing out. |