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 2114

Summary: SDL_CreateWindowAndRenderer causes supposed 12 byte memory leak
Product: SDL Reporter: watermelonst
Component: renderAssignee: Sam Lantinga <slouken>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 2.0.0   
Hardware: x86_64   
OS: Windows 7   
Attachments: Output log from DrMemory on Win7
New log with debug mode on
Debug DLL results

Description watermelonst 2013-09-26 18:42:57 UTC
Created attachment 1339 [details]
Output log from DrMemory on Win7

I run DrMemory on Windows7 64 bit to make sure my application has no memory leakage. I noticed there are three errors that come up when I use SDL_CreateWindowAndRenderer compared to doing SDL_CreateWindow and SDL_CreateRenderer on their own. I free the resources properly at the end and this is the result.

Note that when running it with SDL_CreateWindow/CreateRenderer, DrMemory reports no leaks. Therefore I assume something is up with SDL_CreateWindowAndRenderer.

If there is an hg build I could quickly test for win7 I will do so to see if it was fixed.

In the error log, I do not render anything to the screen (I did my best to fully isolate the lines causing the problem, and these three in the log attached still show up after loading images and rendering. It does not appear to be a major recurring memory leak (after running and getting 300 fps/rendering for minutes on end, it always ends up being 12 bytes leaking).


Code in question attached:
================================================================================

static SDL_Window *g_window;
static SDL_Renderer *g_renderer;

...

// If this is run when SDL_CreateWindowAndRenderer is commented out,
// it runs just fine with no memory leak
g_window = SDL_CreateWindow("Test", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, WINDOW_DEFAULT_X, WINDOW_DEFAULT_Y, SDL_WINDOW_SHOWN);
g_renderer = SDL_CreateRenderer(g_window, -1, SDL_RENDERER_SOFTWARE | SDL_RENDERER_ACCELERATED);

// If this is run and the above two are commented out, a memory leak occurs
SDL_CreateWindowAndRenderer(WINDOW_DEFAULT_X, WINDOW_DEFAULT_Y, SDL_WINDOW_SHOWN, &g_window, &g_renderer);


...

// At the very end
SDL_DestroyRenderer(g_renderer);
SDL_DestroyWindow(g_window);
g_window = NULL;
g_renderer = NULL;
SDL_Quit();
Comment 1 watermelonst 2013-09-26 18:45:59 UTC
Sorry I forgot to add this as it's needed if copy/pasting is done with the above:

#define WINDOW_DEFAULT_X 640
#define WINDOW_DEFAULT_Y 480
Comment 2 watermelonst 2013-09-26 19:43:35 UTC
I removed SDL_RENDERER_ACCELERATED since I was having rendering problems, still no memory leak.
Comment 3 watermelonst 2013-09-26 19:49:59 UTC
Interesting development: As soon as I change the flag from SDL_RENDERER_SOFTWARE to SDL_RENDERER_ACCELERATED the memory leak comes back.
Comment 4 Sam Lantinga 2013-09-28 06:09:23 UTC
That's odd, since SDL_CreateRenderer() doesn't call SDL_GL_UnbindTexture().  How was your version of SDL built?  It might help to get better symbols if you build it yourself in debug mode.
Comment 5 watermelonst 2013-09-28 15:50:58 UTC
Sorry I should have run it in debug mode, my bad.

I added an attachment of the change that comes up between using SDL_RENDERER_SOFTWARE to SDL_RENDERER_HARDWARE

In software, there are zero memory leaks, but hardware is always 12 even though I'm just changing the constant.

If you need anything else I'll do my best to do so.
Comment 6 watermelonst 2013-09-28 15:51:33 UTC
Created attachment 1342 [details]
New log with debug mode on
Comment 7 Sam Lantinga 2013-09-28 17:28:11 UTC
It looks like SDL2 wasn't rebuilt in debug mode.  Can you try that?
Comment 8 watermelonst 2013-09-30 17:00:52 UTC
Sorry this will be a newbie question:
Is that something I can easily do from VC++ 2010? Or do I need to download the source code and manually compile it for a debug release, then use that DLL? Either is fine with me.
Comment 9 Sam Lantinga 2013-10-01 05:18:07 UTC
You need to download the source code and manually compile it for a debug build.
Comment 10 watermelonst 2013-10-01 13:42:32 UTC
Created attachment 1350 [details]
Debug DLL results

I attached the file with the information. If there is anything else I can do please let me know.
Comment 11 Sam Lantinga 2013-10-03 08:01:08 UTC
Getting closer... can you paste line 510 of SDL_render_d3d.c (and a few lines around it?)

On my file, line 510 is this, which doesn't make any sense:
data->pparams.BackBufferFormat = D3DFMT_UNKNOWN;
Comment 12 Sam Lantinga 2013-10-03 08:03:02 UTC
In any case, I don't think it's an SDL issue.  This is inside the NVIDIA D3D wrapper DLL, and is likely a minor memory leak in their code.