Bug 482954 - SOAP memory leak (cursoap not free'd properly)
SOAP memory leak (cursoap not free'd properly)
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: condor (Show other bugs)
1.1
All Linux
medium Severity medium
: 1.1.1
: ---
Assigned To: Matthew Farrellee
Jeff Needle
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-28 19:02 EST by Matthew Farrellee
Modified: 2009-04-21 12:18 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-21 12:18:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Farrellee 2009-01-28 19:02:58 EST
condor-7.2.1-0.1 and before


Run schedd under valgrind...

_CONDOR_USE_CLONE_TO_CREATE_PROCESSES=FALSE valgrind --leak-check=full condor_schedd -t -f -p 1981


Run LeakTest program using libs from x_soap_tests.tar.gz...

import birdbath.*;
import condor.*;
import java.rmi.*;
import java.net.*;

import birdbath.Transaction;

public class LeakTest
{
   public static void main(String[] args)
      throws Throwable
   {
      Schedd schedd = new Schedd(new URL("http://localhost:1981"));

      for (int i = 0; i < 10000; i++) {
         try {
            schedd.getJobAd(42,0);
         } catch (RemoteException exception) {
         }
      }
   }
}


Observe leak from soap_copy...

==29082== 392 bytes in 7 blocks are possibly lost in loss record 35 of 40
==29082==    at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==29082==    by 0x9B8038: soap_copy_context (in /usr/lib/libgsoapssl++.so.0.0.0)
==29082==    by 0x9B823C: soap_copy (in /usr/lib/libgsoapssl++.so.0.0.0)
==29082==    by 0x81824E6: DaemonCore::HandleReq(Stream*) (daemon_core.cpp:3596)
==29082==    by 0x81853A7: DaemonCore::HandleReq(int) (daemon_core.cpp:3215)
==29082==    by 0x8185993: DaemonCore::CallSocketHandler(int&, bool) (daemon_core.cpp:3033)
==29082==    by 0x8187219: DaemonCore::Driver() (daemon_core.cpp:2953)
==29082==    by 0x818F48B: main (daemon_core_main.cpp:2073)
==29082== 
==29082== 
==29082== 439,748 (199,940 direct, 239,808 indirect) bytes in 9,997 blocks are definitely lost in loss record 39 of 40
==29082==    at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==29082==    by 0x9B810B: soap_copy_context (in /usr/lib/libgsoapssl++.so.0.0.0)
==29082==    by 0x9B823C: soap_copy (in /usr/lib/libgsoapssl++.so.0.0.0)
==29082==    by 0x81824E6: DaemonCore::HandleReq(Stream*) (daemon_core.cpp:3596)
==29082==    by 0x81853A7: DaemonCore::HandleReq(int) (daemon_core.cpp:3215)
==29082==    by 0x8185993: DaemonCore::CallSocketHandler(int&, bool) (daemon_core.cpp:3033)
==29082==    by 0x8187219: DaemonCore::Driver() (daemon_core.cpp:2953)
==29082==    by 0x818F48B: main (daemon_core_main.cpp:2073)
==29082== 
==29082== 
==29082== 559,552 bytes in 9,992 blocks are definitely lost in loss record 40 of 40
==29082==    at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==29082==    by 0x9B8038: soap_copy_context (in /usr/lib/libgsoapssl++.so.0.0.0)
==29082==    by 0x9B823C: soap_copy (in /usr/lib/libgsoapssl++.so.0.0.0)
==29082==    by 0x81824E6: DaemonCore::HandleReq(Stream*) (daemon_core.cpp:3596)
==29082==    by 0x81853A7: DaemonCore::HandleReq(int) (daemon_core.cpp:3215)
==29082==    by 0x8185993: DaemonCore::CallSocketHandler(int&, bool) (daemon_core.cpp:3033)
==29082==    by 0x8187219: DaemonCore::Driver() (daemon_core.cpp:2953)
==29082==    by 0x818F48B: main (daemon_core_main.cpp:2073)


Patch "free(cursoap);" in daemon_core.cpp to "soap_free(cursoap);" and re-run, observing all soap_copy leaks are gone.
Comment 1 Matthew Farrellee 2009-01-28 19:26:03 EST
commit 26329d5be5be66f622f8a7793ac82317d50aa353
Author: Matthew Farrellee <matt>
Date:   Wed Jan 28 18:07:54 2009 -0600

    Fixed memory leak in the SOAP interface (soap_copy leak)
    
    DaemonCore::HandleReq(Stream*) was using soap_copy()+free() instead of
    soap_copy()+soap_free(). The result was a few hundred bytes of memory
    would be leaked for each connection. This could eventually cause the
    schedd to run out of memory. This can be tested for by simply making
    SOAP connections repeatedly.
    
    This bug has existed since the SOAP code was originally committed on
    Dec 8 2003, SHA 775e9bee
    
    This was Red Hat BZ482954
    
    VERSION HISTORY: Fixed memory leak in SOAP interface (soap_copy and cursoap 
related), leaking since 8 Dec 2003
Comment 2 Martin Kudlej 2009-02-11 10:33:54 EST
Memory-leak from #1 has been fixed and another one found and filled as bug 485090.
Comment 4 errata-xmlrpc 2009-04-21 12:18:56 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0434.html

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