[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3421.0. "Memory leak when throwing an exception" by TAEC::FLAUW (Marc Flauw, TeMIP Technical Office, VBO) Mon Feb 03 1997 09:20

Hello,

env: D-Unix V3.2G, cxx V5.5

I think have found a memory leak that occurs when throwing an exception.
There seems to be a leak of 448 bytes *per thread* when throwing an
exception. This leak occurs only once per thread and throwing several times
an exception within the same thread shows the leak only once.

The application built with our toolkit receives external requests, services
them and returns the result. A thread is created for each request and for
the duration of the request. As a result, the application creates a large
number of threads that come and go.

This problem has been reported to us as a High priority problem by 2 of our
customers using cxx V5.4. I have built a reproducer attached below that
iteratively creates a thread, which throws an exception and catches it.

I have tested this program with 100 iterations using MemAdvisor and
Memadvisor indicates 448*100 bytes of memory leak.

To be sure that it was a real leak, I have tested this program with 20000
iterations, measuring the virtual size of the program. The virtual size of
the process did grow from 2.84 Mb at startup up to 12.6Mb at the end of the
test. The number of threads in the process did not grow. This represents an
increase of 9.76 Mb, which means approx. 500 bytes per throw and confirms
the MemAdvisor report.

I have redone the same test commenting the "throw e;" line to avoid the
throwing of the exception and the program virtual size stays at 2.84 Mb.
There is no increase of the virtual size due to the creation and
destruction of threads by my test program.

Can you verify if there is a real leak and give us a status as this is
considered by the customer as a High priority problem ?

Attached below:
  1- exact reference of operating system, shared lib and compiler
  2- MemAdvisor report
  3- source of test program
  4- makefile for test program

Thanks and regards,

Marc.
---------------------------------------------------------------  
% uname -a 
OSF1 lauris.vbo.dec.com V3.2 62 alpha

# setld -i | grep CXX | grep installed
CXXBASE550      installed       DEC C++ (cxx) for Digital UNIX
CXXLIB550       installed       DEC C++ static class libraries
CXXMAN550       installed       DEC C++ and class library manual pages
CXXSHRDA307     installed       DEC C++ Class Library, Run-Time Support
CXXV3HDR550     installed       DEC C++ header files for Digital UNIX V3.x
% cxx -V
cxx  (cxx)
DEC C++ V5.5-004 on Digital UNIX (Alpha)



********************** MemAdvise: List of Memory Leaks *********************

    Data                                               Which  Number Total Data
    Address      Stat            Location              Call   Leaks    Leaked  
---------------- ---- ------------------------------- ------  ------ ----------
0x0000000012B818  D   MaLlOc()                         321st       1        448
                      allocate_object_descriptor()
[/usr/proj/cxx1/cxxl_resd/aosf32_maint/src/cxx_exc.c:376]
                      __cxx_throw()  
[/usr/proj/cxx1/cxxl_resd/aosf32_maint/src/cxx_exc.c:460]
                      DoEffectiveThrow() [test_exception.cxx:27]
                      DoThrow()       [test_exception.cxx:38]
         Thread: 101

0x0000000012BA18 **** MaLlOc()                         318th      99      44352
                      allocate_object_descriptor()
[/usr/proj/cxx1/cxxl_resd/aosf32_maint/src/cxx_exc.c:376]
                      __cxx_throw()  
[/usr/proj/cxx1/cxxl_resd/aosf32_maint/src/cxx_exc.c:460]
                      DoEffectiveThrow() [test_exception.cxx:27]
                      DoThrow()       [test_exception.cxx:38]
         Thread: 100


=====================================================================
test_exception.cxx:

#include <cma.h>
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <iostream.hxx> 	// for cout 


int i =0;

// declare typedef for thread routine
typedef void *(*MThreadProc)(void *);


// Empty exception class
class TException
{
public:
  TException() {};
  ~TException() {};
};



void DoEffectiveThrow()
{
  TException e;
  throw e;
}


// Send an exception and catch it
void DoThrow()
{
  try
    {
      i++;
      cout <<"Sending exception " << i <<endl;
      DoEffectiveThrow();
     }
  catch (TException &e)
    {
    }
}

// Create a CMA thread that sends an exception
void DoOnce()
{
  cma_t_thread thread_id;
  cma_t_attr attr = cma_c_null;
  cma_t_exit_status status;
  void *result;


  // Create the thread
  cma_thread_create(&thread_id,&attr,(MThreadProc)DoThrow,NULL);

  // Wait for it to complete
  cma_thread_join(&thread_id,&status,&result);

  // Delete the thread
  cma_thread_detach(&thread_id);
  
  // Wait 20 ms for the thread deletion to be done and 
  // all data associated with the thread to be cleaned-up
  cma_delay(0.02); 
}

void main()
{
  // Initialise thread env.
  cma_init();

  sleep(10);
  // Repeat the test 100 times under MemAdvisor 
  // and 20000 times without Memadvisor
  for (int ii=0; ii<20000;ii++)
    {
      DoOnce();
    }

  sleep(60);
}

=====================================================================
test_exception.make:

CXXFLAGS =  -nopt -w0 -g -O0 
CXX     = cxx
LD++    = $(CXX) -call_shared -o

all:    test_exception

test_exception:        test_exception.o  
	 $(LD++) test_exception test_exception.o -threads

test_exception.o: test_exception.cxx
	 $(CXX) -c $(CXXFLAGS)  test_exception.cxx



T.RTitleUserPersonal
Name
DateLines
3421.1Investigating...DECCXX::MITCHELLMon Feb 03 1997 12:306
Hi Marc,

Thanks for the problem report.  It is quite complete
and also tells us why the issue is important to your
product.  We think we know what's going on, and someone
is looking at it in more detail.
3421.2OkTAEC::FLAUWMarc Flauw, TeMIP Technical Office, VBOTue Feb 04 1997 05:247
Charlie,

Thanks for the answer. We will wait for the results of your investigations.

Best regards,

Marc.