Regarding the apparent memory leaks reported by Windows' CRT on application exit caused by STLport maintaining its own free block list (only for blocks < 128 bytes, it would seem).
Rather than define _STLP_LEAKS_PEDANTIC to force STLport to _really_ release heap blocks every time a block is deallocated (if that's what actually happens), could code be added to STLport's allocator(s) to allow applications to explicitly request that the free blocks are released back to the system (kind of like a garbage collection run)? And I'm thinking there should also be an easy way to trigger this for the default allocator(s).
This way we could preserve STLport's optimized allocator whilst at the same time be able to get that warm wuzzy feeling on application exit when no memory leaks are reported (or more likely, just our own real leaks).
Or is there already a mechanism in place to do this?
I had already read the FAQ, and was writing about an alternative way of handling the pseudo-leak that wouldn't require recompiling with different (inefficient) allocators, or without forcing the release on every free.
Don't you think what I suggested would be useful? i.e. a way to release the freed memory blocks under the control of the application? I certainly would find it useful just to be able to see my real memory leaks listed without the rest of the pseudo-leaks (I can't see the wood for the trees). I suppose I could always switch allocators temporarily whilst testing to find just my own leaks, but that's a lot of work.
How easy would it be to extend the functionality of the default allocator to provide this, or to create a modified allocator? I'm not familiar enough with the allocator code, and it took a lot of debugging to figure out what the allocator currently does (just storing the freed blocks in an internal list).
> Don't you think what I suggested would be useful?
Not useful, IMO.
> i.e. a way to release the freed memory blocks under the control of the application?
> I certainly would find it useful just to be able to see my real memory leaks
> listed without the rest of the pseudo-leaks (I can't see the wood for the trees). I suppose I could always switch allocators temporarily whilst testing to find just my own leaks, but that's a lot of work.
Another tools, beyond the scope of STL.
This is a rather regular request and I would like to make our point of view more clear (at least my point of view). There are several reasons why we won't implement your request:
1. STLport simply implement Standard C++. Even if we have some extensions, we try to avoid integration of new extension, especially in the interface of a Standard class like the std::allocator. Calling some kind of purge method would require a #if STLPORT block which is against C++ portability.
2. Your request would have a major impact on allocator implementation. For the moment the _STLP_LEAK_PEDANTICS only require us to count the number of allocation/deallocation and the big chunk of memory allocated, when counter goes back to 0 we are free to release all the blocks. What you are asking is to track all memory blocks to know when they are available again and then release them, IMO this is exactly what new/delete or malloc/free does, if node allocator was doing the same kind of thing it wouldn't be an interesting allocator anymore for performance.
3. STLport is open source, play with code, does your own allocator directly in the library and submit a patch if you think you have something interesting.
4. There are libraries dedicated to memory allocation issues, STLport only try to have a rather good behaving allocator in the limit of portability and maintenance constrainsts. Try one of those if you want (www.hoard.org).
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.