This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Example to reproduce the crash (sdl_mem_crash.c, text/plain, 2014-04-13 10:17:46 +0000, 889 bytes)

Reported in version: 2.0.3
Reported for operating system, platform: Windows 8, x86_64

Comments on the original bug report:

On 2014-04-13 10:17:46 +0000, Pavlo Ilin wrote:

Created attachment 1618
Example to reproduce the crash

Windows implementation of SDL_malloc/SDL_free/etc. uses dlmalloc instead of CRT malloc. Current settings of dlmalloc are not thread-safe, so it's dangerous to allocate/free memory simultaneously in the separate threads. SDL itself and some libraries like SDL_mixer actually depend on this feature.

Attached is a short example, which reproduces the crash. Usually, crash looks like this: "Unhandled exception at 0x6C7B543D (SDL2.dll) in sdl_mem_crash.exe: 0xC0000005: Access violation reading location 0x00000004"
I used MS Visual Studio 2013 and SDL2-devel-2.0.3-VC x86 library. Debug builds of my test application are more prone to the crash.

I tried to compile my own version of the SDL library with changes in the SDL_malloc.c:

1. Enabling HAVE_MALLOC and use of the CRT memory allocator fixes the problem.
2. Setting USE_LOCKS also fixes the problem, but, as the flag's description says:

When USE_LOCKS is defined, each public call to malloc, free,
etc is surrounded with either a pthread mutex or a win32
spinlock (depending on WIN32). This is not especially fast, and
can be a major bottleneck. It is designed only to provide
minimal protection in concurrent environments, and to provide a
basis for extensions. If you are using malloc in a concurrent
program, consider instead using ptmalloc, which is derived from
a version of this malloc.

Current implementation of SDL_malloc for Windows was introduced in 2006. I'm amazed, that no one have reported this issue.

On 2014-04-18 04:50:00 +0000, Sam Lantinga wrote:

That is amazing that nobody else has reported this. I think we'll look into ptmalloc, since we want to avoid a C runtime dependency. Thanks!

On 2014-04-18 04:59:17 +0000, Sam Lantinga wrote:

For future reference, a version of ptmalloc with a license we can use is available here:
http://www.malloc.de/

On 2014-04-18 06:28:24 +0000, Pavlo Ilin wrote:

Latest version of ptmalloc3 is released 2006 and based on dlmalloc 2.8.3 (same as in SDL). ptmalloc would be probably the easiest to integrate, because it should be the closest relative of dlmalloc. But there are a lot of good allocators. May be it's worth to consider them.

Doug Lea in his latest dlmalloc 2.8.6 also mentions nedmalloc as a possible substitute (http://www.nedprod.com/programs/portable/nedmalloc and https://github.com/ned14/nedmalloc). Nedmalloc claims to be slightly better than ptmalloc3.

jemalloc can be other replacement (http://www.canonware.com/jemalloc/ and https://github.com/jemalloc/jemalloc/). Looks like it is a default allocator in FreeBSD and was used quite successfully in Firefox, Facebook, and Blender.

Both projects were alive in the last years.

On 2014-05-09 18:57:15 +0000, Keith O'Conor wrote:

FYI, I had a crash when cleaning up SDL threads that I debugged and came to the same conclusion as Pavlo - see the discussion thread at http://forums.libsdl.org/viewtopic.php?p=43411 that also has sample code to repro the crash (although Pavlo's is a better example).

I was also surprised that this hasn't come up before now, and only found this bug now when I went to log it myself. Strange timing, nothing for 6 years and then twice in one month!

On 2014-05-10 18:35:19 +0000, Sam Lantinga wrote:

This bug is taken care of for a while, until someone has time to investigate the other malloc() implementations.
https://hg.libsdl.org/SDL/rev/3b1ed6708ce9

Thanks!