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@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Robert Fendt Sent: Thursday, October 19, 2006 10:25 AM To: boost-users@lists.boost.org 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. **********************************************************************************************