I added AddressSanitizer support to debug builds recently to directly show memory leaks when a new patch is committed by a contributor. This works (for me) with the SDL repo in Ubuntu 18.04 and 20.04 using make and ninja.

You reported this against SDL, but it seems you are using a fork of "SDL_mixer" called "SDL-Mixer-X".

- Is your "SDL-Mixer-X" interfering with the original SDL build settings?
- Does this happen with "make" scripts too?
- Does this happened with the original SDL repo?
- Do you have a build-script available that can reproduce this issue?

> - Is your "SDL-Mixer-X" interfering with the original SDL build settings?

My MixerX does link to the original SDL2 build that I do by its original CMake build (I do build it via ExternalProjects thing of my CMake build)

> - Does this happen with "make" scripts too?

Didn't verify, that happens on the Semaphore-CI and I usually don't touch the SDL2 itself, however, I'll try to test it on my local system to find some...

> - Does this happened with the original SDL repo?

My build does use the ExternalProjects thing: it literally downloads the original repo of SDL2 and runs its CMake build in a place.

> - Do you have a build-script available that can reproduce this issue?

The build run was done by this code from here: https://github.com/WohlSoft/AudioCodecs/blob/master/download_sdl2_hg.cmake#L92-L111
(here is an option that allows running the AudioCodecs repo local copy of SDL2 (mainly I keep the release version and if needed, I patch it with some recent fixes))

The build command is probably something like:
```
cmake -DCMAKE_BUILD_TYPE=Release -G Ninja -DSNDIO=OFF -DCMAKE_DEBUG_POSTFIX=d -DSDL_STATIC_PIC=ON -DSDL_SHARED=ON -DSDL_STATIC=ON ..
```
At me locally on Linux Mint 20.1 it got built, gonna try the debug build... The build got failed on Ubuntu 18.04.

Debug build is also a success, now I need to boot up another machine and retry the build again...

Oh, my recent commit to MixerX I did (I backported two of Ozkan's commits from the mainstream Mixer), and the build on a Semaphore-CI has been completed successfully! No idea what you did to fix that, but it's fixed now!

NO! I miss-looked, it still fail...

The "sdl-macos-static-analysis" build-bot has been failing since
the sanitizer patch:
https://buildbot.libsdl.org/#/builders/17

Created attachment 4771 [details]
fix AddressSanitizer linking for clang

I could reproduce this with clang (CC=clang cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug ..).

The attached patch fixes the issue.

(In reply to Christian Rauch from comment #8)
> Created attachment 4771 [details]
> fix AddressSanitizer linking for clang
> 
> I could reproduce this with clang (CC=clang cmake -G Ninja
> -DCMAKE_BUILD_TYPE=Debug ..).
> 
> The attached patch fixes the issue.

Patch applied as https://hg.libsdl.org/SDL/rev/28e3b60e2131

Gonna re-run my Semaphore-CI build...

(In reply to Ozkan Sezer from comment #9)
> (In reply to Christian Rauch from comment #8)
> > Created attachment 4771 [details]
> > fix AddressSanitizer linking for clang
> > 
> > I could reproduce this with clang (CC=clang cmake -G Ninja
> > -DCMAKE_BUILD_TYPE=Debug ..).
> > 
> > The attached patch fixes the issue.
> 
> Patch applied as https://hg.libsdl.org/SDL/rev/28e3b60e2131

The 'sdl-macos-static-analysis' build-bot still fails. Last run:
https://buildbot.libsdl.org/#/builders/17/builds/602

Created attachment 4772 [details]
The second log

My still fail too...

(In reply to Vitaly Novichkov from comment #12)
> Created attachment 4772 [details]
> The second log
> 
> My still fail too...

Your's is using a pretty old GCC (4.8.5). My system is "too new" to be able to test it with this version. But even with this older version, the AddressSanitizer is supposed to link at least as shown here https://github.com/google/sanitizers/issues/1065.

Can you try adding

    check_add_debug_flag("-static-libasan" "static_libasan")

after

    check_add_debug_flag("-shared-libasan" "shared_libasan")

in the CMakeLists.txt and try again?

> Your's is using a pretty old GCC (4.8.5)

That Semaphore-CI image with the Ubuntu 18.04, not me, at my local system the gcc 9.3 is. Anyway, the SDL2 itself is intended to be built on almost any compiler including very old ones.

BTW, IDK what about the Haiku side CMake build support? If it still faulty (at my side the resulted CMake-build had no sound supported, but the "pkgman"-installed worked fine), I'll make a separate bug for this.

Created attachment 4773 [details]
enable AddressSanitizer only for GCC 5 onwards

Older GCC and macOS do not deal well with AddressSanitizer. The attached patch enables this therefore just for GCC versions>=5.

I hope this prevents the reported issues but still allows contributors to detect memory leaks easier.

Useful one, I used that at my work, but, when targeting to the wide set of compilers, make sure the feature is optional and manually toggleable, or at least checkabme for the availability. The CI test I will make once a fix will arrive the repository.

(In reply to Christian Rauch from comment #16)
> Created attachment 4773 [details]
> enable AddressSanitizer only for GCC 5 onwards
> 
> Older GCC and macOS do not deal well with AddressSanitizer. The attached
> patch enables this therefore just for GCC versions>=5.
> 
> I hope this prevents the reported issues but still allows contributors to
> detect memory leaks easier.

Is there a specific reason you are checking CMAKE_CXX_COMPILER_ID
and not CMAKE_C_COMPILER_ID?

Created attachment 4774 [details]
enable AddressSanitizer only for GCC 5 onwards

Since SDL declares that it uses "C" and "CXX" the compiler type check should not matter, but the attached patch changes the check to "CMAKE_C_COMPILER_ID" anyway.

As I know, the reason why CXX is used because of some Haiku API related C++ modules here, the rest of other SDL2 side, the pure-C code is used always.

Wait, I did a check, and I see many cases:
- hidapi
- SDL-thread, the "stdcpp" module
- WinRT part
- Haiku part

(In reply to Christian Rauch from comment #19)
> Created attachment 4774 [details]
> enable AddressSanitizer only for GCC 5 onwards
> 
> Since SDL declares that it uses "C" and "CXX" the compiler type check should
> not matter, but the attached patch changes the check to
> "CMAKE_C_COMPILER_ID" anyway.

We can change CMAKE_CXX_COMPILER_VERSION to CMAKE_C_COMPILER_VERSION, too
I think.

Also, since you want CC >= 5, the condition should be VERSION_GREATER_EQUAL
which would bump our cmake requirement from 3.0 to 3.7, or we can change it
to something like CMAKE_C_COMPILER_VERSION VERSION_GREATER 4 ?

Created attachment 4775 [details]
enable AddressSanitizer only for GCC 5 onwards

patch with correct language name and version

(In reply to Christian Rauch from comment #23)
> Created attachment 4775 [details]
> enable AddressSanitizer only for GCC 5 onwards
> 
> patch with correct language name and version

Patch applied as https://hg.libsdl.org/SDL/rev/1025c399f435

> Patch applied as https://hg.libsdl.org/SDL/rev/1025c399f435

Buildbot no longer fails.

Created attachment 4777 [details]
After recent fix, Ubuntu 18.04 on GCC 4.8.5 is still fail

Unfortunately, on my side, it still fails...

(In reply to Vitaly Novichkov from comment #26)
> Created attachment 4777 [details]
> After recent fix, Ubuntu 18.04 on GCC 4.8.5 is still fail
> 
> Unfortunately, on my side, it still fails...

Does it mean that cmake interprets 4.8.4 > 4?
I.e.: does it work if you change VERSION_GREATER argument
from 4 to 4.99?

I also wonder how things work with clang: Last I remember,
clang reports itself as gcc 4.2.1 for compatibility.

Created attachment 4778 [details]
VERSION_GREATER 9

(In reply to Ozkan Sezer from comment #27)
> (In reply to Vitaly Novichkov from comment #26)
> > Created attachment 4777 [details]
> > After recent fix, Ubuntu 18.04 on GCC 4.8.5 is still fail
> > 
> > Unfortunately, on my side, it still fails...
> 
> Does it mean that cmake interprets 4.8.4 > 4?
> I.e.: does it work if you change VERSION_GREATER argument
> from 4 to 4.99?

YES, here is the confirmation I did by a dummy CMake test

Created attachment 4779 [details]
A small test

I guess, you need to try the:
```
CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL 5
```
for GCC

Nope... the "VERSION_GREATER_EQUAL" requires CMake 3.7+...

(In reply to Ozkan Sezer from comment #27)
> (In reply to Vitaly Novichkov from comment #26)
> > Created attachment 4777 [details]
> > After recent fix, Ubuntu 18.04 on GCC 4.8.5 is still fail
> > 
> > Unfortunately, on my side, it still fails...
> 
> Does it mean that cmake interprets 4.8.4 > 4?
> I.e.: does it work if you change VERSION_GREATER argument
> from 4 to 4.99?
> 
> I also wonder how things work with clang: Last I remember,
> clang reports itself as gcc 4.2.1 for compatibility.

OK, I tested myself using gcc-4.9.4 using a cmake debug build,
it links for me.

So: if gcc <= 4.8 is really the problem, I suggest changing the
VERSION_GREATER argument to 4.8.99, which passes OK for gcc4.9.
With or without that change, it is rejecting clang..

> OK, I tested myself using gcc-4.9.4 using a cmake debug build,
> it links for me.

OK, I take that back: the library itself seems to link, but the test
programs do fail with undefined reference to __asan_stack_free_7 and
similar others.

This has become annoying.

Also, it fails on MinGW on Windows because it can't link the -lasan:
https://ci.appveyor.com/project/Wohlstand/sdl-mixer-x/build/job/06e2304gmkg61n5y#L1785

(In reply to Vitaly Novichkov from comment #34)
> Also, it fails on MinGW on Windows because it can't link the -lasan:

I'm not sure sanitizers have ever been porter to windows.

Created attachment 4780 [details]
make AddressSanitizer optional and disabled by default

This patch disables the AddressSanitizer by default, as compilers other than GCC seem to fail to correctly report the supported compiler flags for the "fsanitize=" category of flags.

The support can be enabled by "-DASAN=ON". I strongly recommend this detect new memory issues (leaks, etc.) before commit patches.

Sorry for the troubles. My intention was to prevent patches from introducing new memory leaks, but the compiler support for this feature seems to be quite poor.

(In reply to Ozkan Sezer from comment #35)
> (In reply to Vitaly Novichkov from comment #34)
> > Also, it fails on MinGW on Windows because it can't link the -lasan:
> 
> I'm not sure sanitizers have ever been porter to windows.

Well, if the sanitisers are not supported, the compiler should not accept them so that "check_c_compiler_flag" can work properly. Anyway, I deactivated this support by default now to prevent further issues with poor compiler support.

Patch applied as https://hg.libsdl.org/SDL/rev/c79dae9f3ba5
Thanks.

Closing as fixed.

Now the build works, thanks to you all guys!