Bug 845521 - Plug memory leak after escaping sequence for console
Summary: Plug memory leak after escaping sequence for console
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-03 10:03 UTC by Alex Jia
Modified: 2013-02-21 07:20 UTC (History)
6 users (show)

Fixed In Version: libvirt-0.10.0-0rc1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 07:20:53 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description Alex Jia 2012-08-03 10:03:25 UTC
Description of problem:
Plug memory leak after escaping sequence for console.

Version-Release number of selected component (if applicable):
# rpm -q libvirt
libvirt-0.10.0-0rc0.el6.x86_64

How reproducible:
alway

Steps to Reproduce:
1. valgrind -v --leak-check=full virsh console <domain>
2. ctrl+]
3.
  
Actual results:

==16663== 4 bytes in 1 blocks are definitely lost in loss record 2 of 32
==16663==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==16663==    by 0x4C7B49B: virAllocN (memory.c:128)
==16663==    by 0x4D4BE6B: virNetClientIOHandleInput (virnetclient.c:1102)
==16663==    by 0x4D4DD6A: virNetClientIOEventLoop (virnetclient.c:1441)
==16663==    by 0x4D4E246: virNetClientSendInternal (virnetclient.c:1662)
==16663==    by 0x4D4E836: virNetClientSendWithReply (virnetclient.c:1863)
==16663==    by 0x4D4F366: virNetClientStreamSendPacket (virnetclientstream.c:360)
==16663==    by 0x4D339E2: remoteStreamAbort (remote_driver.c:4210)
==16663==    by 0x4CF4222: virStreamAbort (libvirt.c:15314)
==16663==    by 0x40A8B8: virConsoleShutdown (console.c:102)
==16663==    by 0x4C7459E: virEventPollRunOnce (event_poll.c:485)
==16663==    by 0x4C73346: virEventRunDefaultImpl (event.c:247)
==16663== 
==16663== LEAK SUMMARY:
==16663==    definitely lost: 4 bytes in 1 blocks

Expected results:
fix memory leak.

Additional info:

Comment 2 Peter Krempa 2012-08-03 15:33:25 UTC
This is a very rare memory leak. It happens only if the daemon crashes while processing the call. Patch sent upstream: http://www.redhat.com/archives/libvir-list/2012-August/msg00203.html

Comment 3 Peter Krempa 2012-08-03 21:49:42 UTC
Fixed upstream:

commit f8ef393ee3a67a61a4c991f50d62652ed81c2ebd
Author: Peter Krempa <pkrempa@redhat.com>
Date:   Fri Aug 3 16:50:16 2012 +0200

    client: Free message when freeing client
    
    The last message of the client was not freed leaking 4 bytes of memory
    in the client when the remote daemon crashed while processing a message.

Moving to POST.

Comment 6 zhe peng 2012-08-24 03:31:03 UTC
can reproduce this with libvirt-0.10.0-0rc0.el6.x86_64

verify with libvirt-0.10.0-0rc1.el6.x86_64

step:
   1. valgrind -v --leak-check=full virsh console <domain>
   2. ctrl+]

==23697== LEAK SUMMARY:
==23697==    definitely lost: 0 bytes in 0 blocks
==23697==    indirectly lost: 0 bytes in 0 blocks
==23697==      possibly lost: 0 bytes in 0 blocks
==23697==    still reachable: 127,799 bytes in 1,376 blocks
==23697==         suppressed: 0 bytes in 0 blocks
==23697== Reachable blocks (those to which a pointer was found) are not shown.
==23697== To see them, rerun with: --leak-check=full --show-reachable=yes

no memory leak ,verification passed.

Comment 7 errata-xmlrpc 2013-02-21 07:20:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html


Note You need to log in before you can comment on or make changes to this bug.