Created attachment 1618 [details]
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.