We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4864

Summary: SDL_DestroyWindow doesn't free memory
Product: SDL Reporter: Francesco <francesco.other>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: ASSIGNED --- QA Contact: Sam Lantinga <slouken>
Severity: critical    
Priority: P2 CC: cameron.gutman, icculus
Version: 2.0.8Keywords: target-2.0.16
Hardware: x86   
OS: Windows 10   
Attachments: Heap allocation before and after test code
Heap before test
Heap after test

Description Francesco 2019-11-17 09:03:14 UTC
Basically, in my program I have sometimes to create and destroy a window. I always use the same window pointer creating and destroying the contents (texture and render).

I notice a memory leak in this process (checking memory usage by the application process) so I wrote a simple program to verify this.

At the end the process occupied 243.4 MB of RAM, at the beginning 7.3 MB.

Here the code in order to reproduce the problem:

------------------------------------------------------

#include <iostream>
#include "SDL.h"


int main(int argc, char *argv[])
{
	SDL_Init(SDL_INIT_VIDEO);

	SDL_Window* mainWindow;
	SDL_Renderer* mainRenderer;
	SDL_Texture* mainTexture;

	for (int i = 0; i < 200; i++)
	{
		mainWindow = SDL_CreateWindow("Memory Leak Test v1.0", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 320, 240, SDL_WINDOW_SHOWN);
		mainRenderer = SDL_CreateRenderer(mainWindow, -1, SDL_RENDERER_ACCELERATED);
		mainTexture = SDL_CreateTexture(mainRenderer, SDL_PIXELFORMAT_ABGR8888, SDL_TEXTUREACCESS_STREAMING, 320, 240);

		if (i == 0)
		{
			std::cout << "SDL Memory Leak Tester, please check the amount of memory\noccupied by the process, then press Enter\n";
			getchar();
		}

		SDL_Delay(50);

		if (i == 199)
		{
			std::cout << "SDL Memory Leak Tester, please check the amount of memory\noccupied by the process, then press Enter\n";
			getchar();
		}

		SDL_DestroyTexture(mainTexture);
		SDL_DestroyRenderer(mainRenderer);
		SDL_DestroyWindow(mainWindow);
	}

	std::cout << "Test finished, press Enter to close\n";
	getchar();

	return 0;
}
Comment 1 Francesco 2019-11-17 13:53:46 UTC
The problem has the higher impact on Windows, on Ubuntu at the end of the test the memory is increased only around 3MB (around 236MB on Windows).
Comment 2 Francesco 2019-11-18 14:04:14 UTC
It doesn't happen with SDL_RENDERER_SOFTWARE
Comment 3 Francesco 2019-11-19 13:43:27 UTC
The behaviour is the same with version 2.0.10 and different rendering drivers
Comment 4 Cameron Gutman 2019-11-22 04:53:23 UTC
I was not able to reproduce this issue here using the latest HG code on Win10 1909 x64. It may have already been fixed or it could be caused by a driver or other software on your machine.

I would suggest using UMDH to get heap allocation stack traces from your affected machine. That will be able to pinpoint the source of the leak.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/using-umdh-to-find-a-user-mode-memory-leak
Comment 5 Francesco 2019-12-02 08:49:55 UTC
Thanks, I will give you all the informations. I have the problem also on a different machine, both ones with Intel UHD Graphics card
Comment 6 Francesco 2019-12-02 10:30:22 UTC
Created attachment 4082 [details]
Heap allocation before and after test code

Here the compare file between 2 log files taken at different time
Comment 7 Francesco 2019-12-02 10:40:16 UTC
Created attachment 4083 [details]
Heap before test
Comment 8 Francesco 2019-12-02 10:40:39 UTC
Created attachment 4084 [details]
Heap after test
Comment 9 Ryan C. Gordon 2020-03-24 20:07:01 UTC
The logs weren't insightful for me, but I'm betting this is something we didn't release correctly in the Direct3D renderer. We made some fixes to this for SDL 2.0.12, but I'd have to look at it more closely to see if this is still leaking.

I assume this _also_ doesn't leak if you force the OpenGL renderer instead of the software one.

--ryan.