# SDL_thread Excessive Memory - Windows

This topic is 2704 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I am currently implementing thread safety into my API. During my usual stress-testing methods of looping 100000 iterations of the same code in search of leaks (and in this case understanding where I can get away with using a semaphore over a mutex by trying to force access violation by blasting 300000 threads at my processor as fast as possible), I noticed leaks of just under 1MB per thread I am running (ends up at ~260mb after 300000 threads have been run).

Now I have looked and I seem to understand that a thread stack is ~1MB, but I can't seem to find any sources explaining why the stack is not cleaning up after itself in SDL_thread. I have also found sources claiming that Windows just leaves the memory there for some sort of caching.

I am simply using the Windows Task Manager to spot the leaks (this may have significance in answering my problem).

Here is the code, it is very simple (in my actual tests the thread functions do different things, but this code produces the same problem):

 int testThreadOne(void* data) { return 0; } int testThreadTwo(void* data) { return 0; } int testThreadThree(void* data) { return 0; } for(int i = 0; i < 100000; ++i) { SDL_CreateThread(testThreadOne, 0); SDL_CreateThread(testThreadTwo, 0); SDL_CreateThread(testThreadThree, 0); }

I am also having similar issues with SDL windows (leaks about 2mb of memory after the first window created, then does not change after that) and Lua (leaks about 500k of memory after the first state is created, then does not change after that).

I want to know:
- Is Windows purposely retaining the memory?
- Is Windows Task Manager unreliable for checking process memory?
- If neither of the above, what is happening?

##### Share on other sites

I want to know:
- Is Windows purposely retaining the memory?
- Is Windows Task Manager unreliable for checking process memory?

Yes, and yes. Windows keeps pages around till everything on the page is freed, even then, the runtimes might free internally for a later allocation and not free back to the OS. There are also other things, like fragmentation to consider, as the application can't free pages back to the OS if it is using even a single byte on the page. So, with a 4KB page, 1KB of data could take up 4MB of virtual memory if you only had one byte active per page. Now, back to task manager. It is showing you all the virtual memory pages allocated to your application, and thusly the number will always be higher than the actual amount of memory your application is using from that address space (it shows 4Mb used, when your application only sees the 1Kb of data you allocated).

##### Share on other sites
Cheers, that clears up the missing information from the sources I found.

1. 1
Rutin
24
2. 2
3. 3
JoeJ
18
4. 4
5. 5

• 38
• 23
• 13
• 13
• 17
• ### Forum Statistics

• Total Topics
631706
• Total Posts
3001835
×