Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 482954

Summary: SOAP memory leak (cursoap not free'd properly)
Product: Red Hat Enterprise MRG Reporter: Matthew Farrellee <matt>
Component: condorAssignee: Matthew Farrellee <matt>
Status: CLOSED ERRATA QA Contact: Jeff Needle <jneedle>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.1CC: mkudlej
Target Milestone: 1.1.1   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-21 16:18:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Farrellee 2009-01-29 00:02:58 UTC
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-29 00:26:03 UTC
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 15:33:54 UTC
Memory-leak from #1 has been fixed and another one found and filled as bug 485090.

Comment 4 errata-xmlrpc 2009-04-21 16:18:56 UTC
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