possible stl memory leak? 
Author Message
 possible stl memory leak?

Hi,

My program runs on NT 4.0. If this function is invoked repetitively without
exiting the program, the NT task manager shows an increase of several MB
virtual memory on this program after each call, and this function takes more
and more time to complete. Virtual C++ and Purify couldn't find any memory
leaks that appear related to this function.

I suspect stl might have something to do with this behavior. This function
uses some local map and vector containers. The objects in those containers
are of char* or int type. The number of objects in the containers may reach
a few millions.

Anyone has some idea about this?

Thanks, Bull



Sat, 15 May 2004 09:15:16 GMT  
 possible stl memory leak?

Quote:
> Hi,

> My program runs on NT 4.0. If this function is invoked repetitively
without
> exiting the program, the NT task manager shows an increase of several MB
> virtual memory on this program after each call, and this function takes
more
> and more time to complete. Virtual C++ and Purify couldn't find any memory
> leaks that appear related to this function.

> I suspect stl might have something to do with this behavior. This function
> uses some local map and vector containers. The objects in those containers
> are of char* or int type. The number of objects in the containers may
reach
> a few millions.

> Anyone has some idea about this?

STL containers do not delete their contents if they are dynamically
allocated.  That is:

std::vector<char*> vec;
char* var = new char[100];
strcpy( var, "hi there" );
vec.push_back( var );
// when vec goes out of scope, var will not be deleted

Might this be your problem?  Also, remember that std::auto_ptr cannot be
used with STL containers.

Sean



Sat, 15 May 2004 09:23:48 GMT  
 possible stl memory leak?

Quote:



> > Hi,

> > My program runs on NT 4.0. If this function is invoked repetitively
>  without
> > exiting the program, the NT task manager shows an increase of several MB
> > virtual memory on this program after each call, and this function takes
>  more
> > and more time to complete. Virtual C++ and Purify couldn't find any memory
> > leaks that appear related to this function.

> > I suspect stl might have something to do with this behavior. This function
> > uses some local map and vector containers. The objects in those containers
> > are of char* or int type. The number of objects in the containers may
>  reach
> > a few millions.

> > Anyone has some idea about this?

> STL containers do not delete their contents if they are dynamically
> allocated.  That is:

> std::vector<char*> vec;
> char* var = new char[100];
> strcpy( var, "hi there" );
> vec.push_back( var );
> // when vec goes out of scope, var will not be deleted

> Might this be your problem?  Also, remember that std::auto_ptr cannot be
> used with STL containers.

> Sean

I use the STL from SGI, and this works on VC++ 6.0 SP 6:
For debugging pourposes, you can use an allocator called malloc_alloc.
This allocator will free the memory when the container is deleted. The
default allocator will show memory leaks (on certain merory leak
detectors) since it maintains a sort of free linked list to avoid
memory fragmentation. This is more efficient but some detectors will
show it as a leak. For debuggin purpoises, you can do this:

#ifdef _DEBUG
  typedef std::vector<char*, std::malloc_alloc> MYVECTOR;
#else
  typedef std::vector<char*> MYVECTOR;
#endif
MYVECTOR _myVector;

Now should work.

Gabriel



Sat, 15 May 2004 21:06:50 GMT  
 possible stl memory leak?
    malloc_alloc does not work as you think it does.  It allocate memory for
the stored object using malloc.  But here the "stored object" is the char*
itself, not the character array pointed to by that char*.

--
Truth,
James Curran
www.NJTheater.com     (Professional)
www.NovelTheory.com  (Personal)
www.BrandsForLess.Com (Day Job)


Quote:
> I use the STL from SGI, and this works on VC++ 6.0 SP 6:
> For debugging pourposes, you can use an allocator called malloc_alloc.
> This allocator will free the memory when the container is deleted. The
> default allocator will show memory leaks (on certain merory leak
> detectors) since it maintains a sort of free linked list to avoid
> memory fragmentation. This is more efficient but some detectors will
> show it as a leak. For debuggin purpoises, you can do this:

> #ifdef _DEBUG
>   typedef std::vector<char*, std::malloc_alloc> MYVECTOR;
> #else
>   typedef std::vector<char*> MYVECTOR;
> #endif
> MYVECTOR _myVector;

> Now should work.

> Gabriel



Sat, 15 May 2004 23:45:01 GMT  
 possible stl memory leak?

Quote:


> > Hi,

> > My program runs on NT 4.0. If this function is invoked repetitively
> without
> > exiting the program, the NT task manager shows an increase of several MB
> > virtual memory on this program after each call, and this function takes
> more
> > and more time to complete. Virtual C++ and Purify couldn't find any
memory
> > leaks that appear related to this function.

> > I suspect stl might have something to do with this behavior. This
function
> > uses some local map and vector containers. The objects in those
containers
> > are of char* or int type. The number of objects in the containers may
> reach
> > a few millions.

> > Anyone has some idea about this?

> STL containers do not delete their contents if they are dynamically
> allocated.  That is:

> std::vector<char*> vec;
> char* var = new char[100];
> strcpy( var, "hi there" );
> vec.push_back( var );
> // when vec goes out of scope, var will not be deleted

> Might this be your problem?  Also, remember that std::auto_ptr cannot be
> used with STL containers.

No. That kind of leak would be found by Visual C++ or Purify.

Bull



Sun, 16 May 2004 02:31:19 GMT  
 possible stl memory leak?
I'm sorry, you're right. I re read the docs and it say that
malloc_alloc maintains a counter of the containers using that
allocator. When no more container uses the allocator (usually rigth
before the program exit) it will free the memory chuncks it gathered
while the program was running. This is why some memory leak detectors
show that memory is still allocated.

In this case, char* are retained by the allocator, not the array
pointed by the pointer.

Quote:

> malloc_alloc does not work as you think it does.  It allocate memory for
> the stored object using malloc.  But here the "stored object" is the char*
> itself, not the character array pointed to by that char*.

> --
> Truth,
> James Curran
> www.NJTheater.com     (Professional)
> www.NovelTheory.com  (Personal)
> www.BrandsForLess.Com (Day Job)



> > I use the STL from SGI, and this works on VC++ 6.0 SP 6:
> > For debugging pourposes, you can use an allocator called malloc_alloc.
> > This allocator will free the memory when the container is deleted. The
> > default allocator will show memory leaks (on certain merory leak
> > detectors) since it maintains a sort of free linked list to avoid
> > memory fragmentation. This is more efficient but some detectors will
> > show it as a leak. For debuggin purpoises, you can do this:

> > #ifdef _DEBUG
> >   typedef std::vector<char*, std::malloc_alloc> MYVECTOR;
> > #else
> >   typedef std::vector<char*> MYVECTOR;
> > #endif
> > MYVECTOR _myVector;

> > Now should work.

> > Gabriel



Sun, 16 May 2004 04:13:38 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Possible memory leaks in char type?

2. Variadic functions & possible memory leak

3. Possible Memory Leak in CRT?

4. Possible Memory Leak in CRT?

5. Possible Memory Leak in CRT?

6. possible memory leak

7. CBitmap and possible memory leak

8. GC - Is it possible to leak memory?

9. Memory Leak with vector STL

10. memory leaks in STL queue?

11. STL Leaks Memory

12. VC6 sp2 Leaks Memory Using STL

 

 
Powered by phpBB® Forum Software