Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_SetMemoryFunctions causes heap pointer fault with custom free() function #3043

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Comments

@SDLBugzilla
Copy link
Collaborator

@SDLBugzilla SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.9
Reported for operating system, platform: Windows 10, All

Comments on the original bug report:

On 2018-10-29 20:41:09 +0000, Anthony @ POW Games wrote:

Essentially, SDL has already used alloc() before main() is called, so a custom free() will fail.

On 2018-10-30 00:01:07 +0000, Ryan C. Gordon wrote:

This is fixed in https://hg.libsdl.org/SDL/rev/68c87b40b434

I'm nervous about making this change right before shipping 2.0.9, so please test this!

--ryan.

On 2018-10-30 00:46:59 +0000, Anthony @ POW Games wrote:

Can you quickly update the binaries at https://www.libsdl.org/tmp/download-2.0.php? I'm still not sure how to build from source unless I'm working with Android.

On 2018-10-30 03:19:52 +0000, Sam Lantinga wrote:

Done!

On 2018-10-30 05:54:52 +0000, Ozkan Sezer wrote:

SDL2-devel-2.0.9-VC.zip is not OK: SDL2main.lib in there is outdated.

On 2018-10-30 09:09:56 +0000, Anthony @ POW Games wrote:

Still not working when trying the latest binaries. Custom free() fails when called from main_getcmdline(). The date-stamp for SDL2main.lib didn't update, which I assume is where the fix should be?

On 2018-10-30 13:56:11 +0000, Sam Lantinga wrote:

Right, updated now, thanks!

On 2018-10-30 15:00:08 +0000, Anthony @ POW Games wrote:

Ok, thanks. no crashes now.

But when I put a counter in, I'm left with memory blocks not freed.

I'm only incrementing the counter when realloc is passed a non-null.

The following code causes 2 blocks to not be freed:

SDL_Init(SDL_INIT_EVERYTHING);
SDL_Quit();

And bizarrely the following code leaves 8 blocks not freed.

SDL_Init(SDL_INIT_AUDIO);
SDL_Quit();

Is this anomalous? A different issue maybe?

On 2018-10-30 15:18:58 +0000, Sam Lantinga wrote:

Yes, this is a different issue. There are a couple places where we leak small amounts of memory because it's hard to tell when the application will actually be done with it. There might also be a legitimate bug in there as well.

Thanks!

On 2018-11-01 21:37:17 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 8)

Yes, this is a different issue. There are a couple places where we leak
small amounts of memory because it's hard to tell when the application will
actually be done with it. There might also be a legitimate bug in there as
well.

This is the only one I see in loopwave.c, fwiw ...

==31490== 776 bytes in 1 blocks are still reachable in loss record 160 of 178
==31490== at 0x4C2DB2F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31490== by 0x4ED5874: SDL_malloc_REAL (SDL_malloc.c:5328)
==31490== by 0x4ED7273: SDL_GetErrBuf (SDL_thread.c:243)
==31490== by 0x4E590BC: SDL_ClearError_REAL (SDL_error.c:152)
==31490== by 0x4E571C2: SDL_InitSubSystem_REAL (SDL.c:114)
==31490== by 0x4E573C1: SDL_Init_REAL (SDL.c:256)
==31490== by 0x4E6F65D: SDL_Init (SDL_dynapi_procs.h:85)
==31490== by 0x108CA6: main (loopwave.c:123)

...the rest are all tiny leaks from PulseAudio, D-Bus, and dlopen() entirely beyond our control.

--ryan.

On 2018-11-02 23:26:44 +0000, Sam Lantinga wrote:

Yup, and this memory is intentionally left allocated after SDL_Quit()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant