Re: [Boost-users] Memory problem using shared_ptr w/ STL-containers, gcc

From: Baranowski, Daniel (dbaranowski_at_[hidden])
Date: 2006-10-19 14:25:46

Hey Robert,

If you change your A class to look like this:
class A {
public:
   A(int iID) : a(iID) {}
   ~A() { std::cout << "Destroying " << a << std::endl; }
  int a;
  int b;
};

You'll see that the objects are or are not getting destroyed (they are
on my comp). I played around with this in VC 8 and the memory usage
didn't go up like yours. Here's how it looks on my system:

With n = 10
-----------------------
In release mode
   Pre: 1,336K
   After new's: 1,336K
   After deletes: 1,336K

In debug mode
   Pre: 1,640K
   After new's: 1,652K
   After deletes: 1,652K

With n = 100,000
-----------------------
In release mode
   Pre: 1,336K
   After new's: 10,568K
   After deletes: 1,432K

In debug mode:
   Pre: 1,640K
   After new's: 20,668K
   After deletes: 1,776K

So, at least on my computer there isn't a memory leak, but it's hard to
tell that when using such a small n. While mine did go up with n = 10 in
release mode, it didn't go up 150k, that seems like a lot to me! Maybe
someone with a better understanding of memory usage could give you a
better explanation as to what's really going on, but I don't think you
have a real memory leak.

Maybe try it without the shared_ptr, just a list of A objects and see
how your memory does then, but increase the size of your A class to
compensate for the shared_prt not being stored (which is an unsigned int
and a pointer, so 8 bytes on a 32bit machine).

Regards,
Daniel

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Robert Fendt
> Sent: Thursday, October 19, 2006 10:25 AM
> To: boost-users_at_[hidden]
> Subject: [Boost-users] Memory problem using shared_ptr w/ STL-
> containers,gcc
> 
> Hi,
> 
> I have a somewhat peculiar problem concerning the shared_ptr template.
> I use an STL container to hold several shared_ptr values. When the
> container is destroyed, all the destructors are called correctly, but
> the memory is not freed. Furthermore, shared_ptr usage introduces a
> 100x memory overhead (or more) in my case. Compiler system is GCC.
> 
.. snip ..
> 
> Between the first and the second stop, the program size in memory
grows
> by about 150k... and that's for 10 objects which are <20 bytes large,
> individually. And to top it off, it leaks memory. Between stops two
and
> three the memory *should* be freed since the scope is left. I can
> include a destructor doing debug output in the class which shows that
> the objects are indeed destroyed. But the memory stays allocated.
> 
> I suspect this is a GCC problem, but I have actually no clue... I
> tested it on a recent Debian "Unstable" and an Ubuntu "Breezy". GCC
> versions varying from 3.2 to 4.1. Or do I use the template in a wrong
> way? Suggestions would be very welcome... and if this is a known bug
in
> GCC, a feasible work-around would be great.
> 
> Thanks in advance,
> Robert
**********************************************************************************************
Disclaimer - This email and any files transmitted with it are proprietary and may contain privileged or copyright information. You must not present this message to another party without 
gaining permission from the sender. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify 
us. If you have received this message in error, please notify the sender immediately, and delete this email from your system. We do not guarantee that this material is free from viruses or any 
other defects although due care has been taken to minimize the risk. eSafe scanned this email for viruses, vandals and malicious contentAny views expressed in this message are those of 
the individual sender, except where the sender specifically states them to be the views of LSI.
**********************************************************************************************