RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 690734 - virsh memory leak with failed connection attempts
Summary: virsh memory leak with failed connection attempts
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-25 08:13 UTC by Alex Jia
Modified: 2011-10-20 19:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-20 19:18:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
memory leak information (14.32 KB, text/plain)
2011-03-25 08:13 UTC, Alex Jia 		no flags Details
View All

Description Alex Jia 2011-03-25 08:13:41 UTC 
Created attachment 487500 [details]
memory leak information

Description of problem:
Running virsh qemu-monitor-command with a incorrect command string will lead to memory leak.


Version-Release number of selected component (if applicable):
# uname -r
2.6.32-120.el6.x86_64
# rpm -q libvirt
libvirt-0.8.7-14.el6.x86_64
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.152.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. valgrind --leak-check=full virsh qemu-monitor-command vr-rhel6-x86_64-kvm '{"execute":"human-monitor-command","arguments":{"command-line":"info kvm"}'
2.
3.
  
Actual results:
error: out of memory.

Expected results:
fix it

Additional info:
Please see attachment.
Comment 2 Osier Yang 2011-03-25 08:43:10 UTC 
it's same problem with https://bugzilla.redhat.com/show_bug.cgi?id=688723， what you see "out of memory" is a misleading error.

*** This bug has been marked as a duplicate of bug 688723 ***
Comment 3 Alex Jia 2011-03-25 14:27:30 UTC 
(In reply to comment #2)
> it's same problem with https://bugzilla.redhat.com/show_bug.cgi?id=688723， what
> you see "out of memory" is a misleading error.
> 
> *** This bug has been marked as a duplicate of bug 688723 ***

Osier,
You mean the following missing memory byte is acceptable, right?
==13864== LEAK SUMMARY:
==13864==    definitely lost: 42 bytes in 3 blocks


Alex
Comment 4 Eric Blake 2011-03-25 14:33:58 UTC 
(In reply to comment #3)
> You mean the following missing memory byte is acceptable, right?
> ==13864== LEAK SUMMARY:
> ==13864==    definitely lost: 42 bytes in 3 blocks

No, that is not okay.  Reopening this bug.  Meanwhile, can you provide more details: what does valgrind --leak-check=full list as the backtrace that allocated the leaked memory?
Comment 5 Alex Jia 2011-03-25 14:53:37 UTC 
(In reply to comment #4)
> (In reply to comment #3)
> > You mean the following missing memory byte is acceptable, right?
> > ==13864== LEAK SUMMARY:
> > ==13864==    definitely lost: 42 bytes in 3 blocks
> 
> No, that is not okay.  Reopening this bug.  Meanwhile, can you provide more
> details: what does valgrind --leak-check=full list as the backtrace that
> allocated the leaked memory?

Hi Eric,
I have provided it in the attachment, please see attachment, if information is not enough, please let me know.


Alex
Comment 6 Eric Blake 2011-03-25 21:01:08 UTC 
Upstream patch posted to plug the leak listed in the attachment:
https://www.redhat.com/archives/libvir-list/2011-March/msg01196.html
Comment 7 RHEL Program Management 2011-04-04 01:46:42 UTC 
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 8 Eric Blake 2011-04-04 16:51:25 UTC 
Memory leaks are never good; however, the first round upstream patch in comment 6 was rejected with more work required.  Requesting exception to allow more time to get this fixed in time for 6.1.
Comment 13 Dave Allan 2011-10-20 19:13:39 UTC 
(In reply to comment #6)
> Upstream patch posted to plug the leak listed in the attachment:
> https://www.redhat.com/archives/libvir-list/2011-March/msg01196.html

Eric, did we take this patch upstream?  If so, I'm going to close the BZ.
Comment 14 Eric Blake 2011-10-20 19:18:39 UTC 
I don't know that the particular patch mentioned in comment 6 was specifically included, but that area of code has been completely rewritten upstream due to the new RPC code.  I think it is safe to mark this as closed, and any new leaks should be new BZ with a stacktrace to the current state of code.
Note You need to log in before you can comment on or make changes to this bug.