problem with memory alocation

Hi to all!

Some time ago I have a strange problem with memory alocation (while using stl containers). I attached c++ source files (ok.cpp and fail.cpp). In ok.cpp everything work "almost" fine, I mean almost all the memory is released after deleting all the elements. BUT the number of 500*8 elements on the list seems to be a limit somehow. In fail.cpp, the number of elements on the list is 500*16 (the size of single element is decreased to 1024*64 from 1024*128). Here, after deleting all the elements of the list and going out of the scope where the list is declared, there is no memory released.
1 How is that possible?
2 What to do? How to fix it?
Thanks for ANY help.

I dont see any attached files.

1. "no memory released" it means that the process does not release some memory to the OS?
2. If so, it is possible because the standard memory allocator builds its own structures on top of the system memory API. Depending on the OS and preferences of the library authors it may not ever release memory back to the OS.

Can you display a report with leaks?

#include <list>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

using namespace std;

int main(int argc, char *argv[])
{
{
printf ("Allocating\n");
list<char*> testList;
for (int a = 0; a < 500 * 16; a++)
{
char *test = new char[1024 * 64];
memset(test, 'A', 1024 * 64);
testList.push_back(test);
}
usleep(10000000);

printf ("Deallocating\n");
for (list<char*>::iterator a = testList.begin(); a != testList.end(); a++)
{
delete[] *a;
}
}

usleep(10000000);

return 0;
}
Hi, debagger does not show any memory leaks in this case. I check memory usage in 'top' processes list.

I see, if debugger does not report any memory leak, you shouldn't worry? As mentioned above, the std::list might maintain some extra data released by OS at exit. Also, not sure if top is the best choice for memory profiling..

I checked several times. I'm pretty sure there is a leak.

Why not run it with Valgrind to find out if there is a problem or not?

Atheist, you're right.
Valgrind can help you Angry100500 - this is the most reliable tool for Linux. For windows you can use purify, memcheck, deleaker, vld... Check your code! Then you'll know where is undeleted object

I checked the code, but the report does not contain any leakage.

I think it would be useful to read about a problem similar to yours. Perhaps here you will find the answers?
http://compgroups.net/comp.unix.prog...-that-o/142500

Thank you. But I can not find the leak!

Perhaps there is some discrepancy between the size of the array and the memory that is allocated for it?