Linux: Segfaults with 8-16x MSAA in GLES2 contexts (Mesa)

[puckyoulol]

Affected project example: https://github.com/fishyhotel/FishyHotel

Random segmentation faults occur when requesting 8x MSAA in an OpenGL ES 2.0 context via SDL2 on Linux with recent Mesa drivers. Lower samples (4x, 2x, or 0) work stably.

Segmentation faults occur every time when requesting MSAA 16x.

The issue appeared after upgrading SDL2 from ~2.26 (Debian 12) to ~2.32 (Debian 13), suggesting a possible regression in SDL2's GLES handling interacting with newer Mesa.

Downgrading SDL2 to 2.26 (Debian 12) fixed this issue.

wget http://deb.debian.org/debian/pool/main/libs/libsdl2/libsdl2-2.0-0_2.26.5+dfsg-1_amd64.deb
wget http://deb.debian.org/debian/pool/main/libs/libsdl2/libsdl2-dev_2.26.5+dfsg-1_amd64.deb
dpkg -i libsdl2-2.0-0_2.26.5+dfsg-1_*.deb
dpkg -i libsdl2-dev_2.26.5+dfsg-1_*.deb

• Instructions: Compile with gcc main.c -Ofast -lSDL2 -lGLESv2 -lEGL -lm -o FishyHotel_linux, run repeatedly → crashes randomly with 8x → crashes every time with 16x.
• On line 1283 you can change the MSAA value int msaa = 16;. Changing this to 0 or 4 solves the problem. 8 = intermittent crashes, 16 = crashes every time.

Environment:

• OS: Debian GNU/Linux 13 (trixie)
• SDL2 version: 2.32.4
• Mesa version: OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.3.0-devel
• GPU: 6900xt & 6700xt (Tested)
• Windowing: X11

[madebr]

Running FishyHotel against current SDL2 master, I see a use-after-free:

Use after free

==17304==ERROR: AddressSanitizer: heap-use-after-free on address 0x7cb04e9e7e48 at pc 0x7f8050d40512 bp 0x7ffeac1974a0 sp 0x7ffeac197498
READ of size 8 at 0x7cb04e9e7e48 thread T0
    #0 0x7f8050d40511 in X11_DispatchEvent /home/maarten/projects/SDL/src/video/x11/SDL_x11events.c:904
    #1 0x7f8050d4b119 in X11_PumpEvents /home/maarten/projects/SDL/src/video/x11/SDL_x11events.c:1754
    #2 0x7f80506a5828 in SDL_PumpEventsInternal /home/maarten/projects/SDL/src/events/SDL_events.c:917
    #3 0x7f80506a5f50 in SDL_WaitEventTimeout_REAL /home/maarten/projects/SDL/src/events/SDL_events.c:1077
    #4 0x7f80506a5985 in SDL_PollEvent_REAL /home/maarten/projects/SDL/src/events/SDL_events.c:959
    #5 0x7f805068c41a in SDL_PollEvent /home/maarten/projects/SDL/src/dynapi/SDL_dynapi_procs.h:156
    #6 0x000000449332 in main_loop /tmp/FishyHotel/main.c:639
    #7 0x00000044c55f in main /tmp/FishyHotel/main.c:1416
    #8 0x7f804fc12574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #9 0x7f804fc12627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #10 0x000000400844 in _start (/tmp/FishyHotel/FishyHotel_dbg+0x400844) (BuildId: b43efe56719ee826bb2a6d9161ef5377f59d263c)

0x7cb04e9e7e48 is located 8 bytes inside of 328-byte region [0x7cb04e9e7e40,0x7cb04e9e7f88)
freed by thread T0 here:
    #0 0x7f80534e5beb in free.part.0 (/lib64/libasan.so.8+0xe5beb) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #1 0x7f8050956222 in real_free /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5199
    #2 0x7f8050956795 in SDL_free_REAL /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5339
    #3 0x7f8050d95262 in SetupWindowData /home/maarten/projects/SDL/src/video/x11/SDL_x11window.c:371
    #4 0x7f8050d9989f in X11_CreateWindow /home/maarten/projects/SDL/src/video/x11/SDL_x11window.c:667
    #5 0x7f8050be54de in SDL_CreateWindow_REAL /home/maarten/projects/SDL/src/video/SDL_video.c:1826
    #6 0x7f805068fccc in SDL_CreateWindow /home/maarten/projects/SDL/src/dynapi/SDL_dynapi_procs.h:545
    #7 0x00000044c295 in main /tmp/FishyHotel/main.c:1304
    #8 0x7f804fc12574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #9 0x7f804fc12627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #10 0x000000400844 in _start (/tmp/FishyHotel/FishyHotel_dbg+0x400844) (BuildId: b43efe56719ee826bb2a6d9161ef5377f59d263c)

previously allocated by thread T0 here:
    #0 0x7f80534e68a3 in calloc (/lib64/libasan.so.8+0xe68a3) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #1 0x7f80509561e3 in real_calloc /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5197
    #2 0x7f80509566e4 in SDL_calloc_REAL /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5311
    #3 0x7f8050d93424 in SetupWindowData /home/maarten/projects/SDL/src/video/x11/SDL_x11window.c:258
    #4 0x7f8050d9989f in X11_CreateWindow /home/maarten/projects/SDL/src/video/x11/SDL_x11window.c:667
    #5 0x7f8050be54de in SDL_CreateWindow_REAL /home/maarten/projects/SDL/src/video/SDL_video.c:1826
    #6 0x7f805068fccc in SDL_CreateWindow /home/maarten/projects/SDL/src/dynapi/SDL_dynapi_procs.h:545
    #7 0x00000044c295 in main /tmp/FishyHotel/main.c:1304
    #8 0x7f804fc12574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #9 0x7f804fc12627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #10 0x000000400844 in _start (/tmp/FishyHotel/FishyHotel_dbg+0x400844) (BuildId: b43efe56719ee826bb2a6d9161ef5377f59d263c)

SUMMARY: AddressSanitizer: heap-use-after-free /home/maarten/projects/SDL/src/video/x11/SDL_x11events.c:904 in X11_DispatchEvent
Shadow bytes around the buggy address:
  0x7cb04e9e7b80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7cb04e9e7c00: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa
  0x7cb04e9e7c80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7cb04e9e7d00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7cb04e9e7d80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x7cb04e9e7e00: fa fa fa fa fa fa fa fa fd[fd]fd fd fd fd fd fd
  0x7cb04e9e7e80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7cb04e9e7f00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7cb04e9e7f80: fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7cb04e9e8000: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7cb04e9e8080: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==17304==ABORTING

It appears testautomation also triggers an error:

Use-after-free in testautomation

test/testautomation  --filter video_getWindowSurface

==17520==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c809052eff0 at pc 0x7fb091f715d8 bp 0x7ffc10bd2c50 sp 0x7ffc10bd2c48
READ of size 8 at 0x7c809052eff0 thread T0
    #0 0x7fb091f715d7 in SDL_DestroyTexture_REAL /home/maarten/projects/SDL/src/render/SDL_render.c:4359
    #1 0x7fb0923d3f27 in SDL_DestroyWindowTexture /home/maarten/projects/SDL/src/video/SDL_video.c:407
    #2 0x7fb0923f24a3 in SDL_DestroyWindowSurface_REAL /home/maarten/projects/SDL/src/video/SDL_video.c:2839
    #3 0x7fb0923f8427 in SDL_DestroyWindow_REAL /home/maarten/projects/SDL/src/video/SDL_video.c:3343
    #4 0x7fb091e9020c in SDL_DestroyWindow /home/maarten/projects/SDL/src/dynapi/SDL_dynapi_procs.h:580
    #5 0x0000004756b9 in video_getWindowSurface /home/maarten/projects/SDL/test/testautomation_video.c:2249
    #6 0x00000049ecb4 in SDLTest_RunTest /home/maarten/projects/SDL/src/test/SDL_test_harness.c:261
    #7 0x0000004a0e5d in SDLTest_RunSuites /home/maarten/projects/SDL/src/test/SDL_test_harness.c:582
    #8 0x000000402a48 in main /home/maarten/projects/SDL/test/testautomation.c:105
    #9 0x7fb091412574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #10 0x7fb091412627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #11 0x000000401c44 in _start (/home/maarten/projects/SDL/cmake-build-debug/test/testautomation+0x401c44) (BuildId: 7bc434508fc71ccf9e60fd4220429910aba79c6c)

0x7c809052eff0 is located 0 bytes inside of 144-byte region [0x7c809052eff0,0x7c809052f080)
freed by thread T0 here:
    #0 0x7fb094ce5beb in free.part.0 (/lib64/libasan.so.8+0xe5beb) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #1 0x7fb092156222 in real_free /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5199
    #2 0x7fb092156795 in SDL_free_REAL /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5339
    #3 0x7fb091f7201c in SDL_DestroyTexture_REAL /home/maarten/projects/SDL/src/render/SDL_render.c:4394
    #4 0x7fb091f7288f in SDL_DestroyRendererWithoutFreeing /home/maarten/projects/SDL/src/render/SDL_render.c:4431
    #5 0x7fb0923f841b in SDL_DestroyWindow_REAL /home/maarten/projects/SDL/src/video/SDL_video.c:3340
    #6 0x7fb091e9020c in SDL_DestroyWindow /home/maarten/projects/SDL/src/dynapi/SDL_dynapi_procs.h:580
    #7 0x0000004756b9 in video_getWindowSurface /home/maarten/projects/SDL/test/testautomation_video.c:2249
    #8 0x00000049ecb4 in SDLTest_RunTest /home/maarten/projects/SDL/src/test/SDL_test_harness.c:261
    #9 0x0000004a0e5d in SDLTest_RunSuites /home/maarten/projects/SDL/src/test/SDL_test_harness.c:582
    #10 0x000000402a48 in main /home/maarten/projects/SDL/test/testautomation.c:105
    #11 0x7fb091412574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #12 0x7fb091412627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #13 0x000000401c44 in _start (/home/maarten/projects/SDL/cmake-build-debug/test/testautomation+0x401c44) (BuildId: 7bc434508fc71ccf9e60fd4220429910aba79c6c)

previously allocated by thread T0 here:
    #0 0x7fb094ce68a3 in calloc (/lib64/libasan.so.8+0xe68a3) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #1 0x7fb0921561e3 in real_calloc /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5197
    #2 0x7fb0921566e4 in SDL_calloc_REAL /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5311
    #3 0x7fb091f3e644 in SDL_CreateTexture_REAL /home/maarten/projects/SDL/src/render/SDL_render.c:1361
    #4 0x7fb0923d2c74 in SDL_CreateWindowTexture /home/maarten/projects/SDL/src/video/SDL_video.c:333
    #5 0x7fb0923f0b8e in SDL_CreateWindowFramebuffer /home/maarten/projects/SDL/src/video/SDL_video.c:2755
    #6 0x7fb0923f1577 in SDL_GetWindowSurface_REAL /home/maarten/projects/SDL/src/video/SDL_video.c:2790
    #7 0x7fb091e900a6 in SDL_GetWindowSurface /home/maarten/projects/SDL/src/dynapi/SDL_dynapi_procs.h:571
    #8 0x000000475661 in video_getWindowSurface /home/maarten/projects/SDL/test/testautomation_video.c:2243
    #9 0x00000049ecb4 in SDLTest_RunTest /home/maarten/projects/SDL/src/test/SDL_test_harness.c:261
    #10 0x0000004a0e5d in SDLTest_RunSuites /home/maarten/projects/SDL/src/test/SDL_test_harness.c:582
    #11 0x000000402a48 in main /home/maarten/projects/SDL/test/testautomation.c:105
    #12 0x7fb091412574 in __libc_start_call_main (/lib64/libc.so.6+0x3574) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #13 0x7fb091412627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627) (BuildId: 8569a90e9859345324d8d0374c16836929c0761a)
    #14 0x000000401c44 in _start (/home/maarten/projects/SDL/cmake-build-debug/test/testautomation+0x401c44) (BuildId: 7bc434508fc71ccf9e60fd4220429910aba79c6c)

SUMMARY: AddressSanitizer: heap-use-after-free /home/maarten/projects/SDL/src/render/SDL_render.c:4359 in SDL_DestroyTexture_REAL
Shadow bytes around the buggy address:
  0x7c809052ed00: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  0x7c809052ed80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7c809052ee00: fd fd fa fa fa fa fa fa fa fa fd fd fd fd fd fd
  0x7c809052ee80: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
  0x7c809052ef00: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
=>0x7c809052ef80: fd fd fd fd fd fd fa fa fa fa fa fa fa fa[fd]fd
  0x7c809052f000: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x7c809052f080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7c809052f100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7c809052f180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7c809052f200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==17520==ABORTING

[puckyoulol]

Does SDL2 still receive updates? Would the SDL2 binaries receive the fix or would it be merged into SDL3?

Meaning the final release of SDL2 binaries would be permanently broken?

[icculus]

We did an SDL2 release in September; we're working on it much less, and generally only bugfixes, but it's still supported and common to see in use still.

Eventually we'll assume everyone has moved over to SDL3 (or at least sdl2-compat), but even then, we'll still accept PRs and accumulate fixes in revision control after we stop making official releases; this is how we handled SDL1, as well.

I'll take a look at the use-after-free issue.

[icculus]

I don't trigger a valgrind issue, but it's notable where this is being freed in the posted stack:

0x7cb04e9e7e48 is located 8 bytes inside of 328-byte region [0x7cb04e9e7e40,0x7cb04e9e7f88)
freed by thread T0 here:
    #0 0x7f80534e5beb in free.part.0 (/lib64/libasan.so.8+0xe5beb) (BuildId: 4386f3fdd17c14d95efd91d6e6589d3e48629889)
    #1 0x7f8050956222 in real_free /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5199
    #2 0x7f8050956795 in SDL_free_REAL /home/maarten/projects/SDL/src/stdlib/SDL_malloc.c:5339
    #3 0x7f8050d95262 in SetupWindowData /home/maarten/projects/SDL/src/video/x11/SDL_x11window.c:371

SDL_x11window.c:371:

error_cleanup:    // <-- SOMETHING OBVIOUSLY WENT VERY WRONG IN WINDOW CREATION.
#ifdef X_HAVE_UTF8_STRING
    if (data->ic) {
        X11_XDestroyIC(data->ic);
    }
#endif
    SDL_free(data);   // <-- LINE 371
    return -1;

[slouken]

Out of curiosity, does it work with sdl2-compat?

[puckyoulol]

Out of curiosity, does it work with sdl2-compat?

Yes just tested sdl2-compat and all affected applications seem to be working fine under sdl2-compat.

sudo apt install libsdl2-compat-dev no recompile was required and all SDL binaries affected started working without any segfaults when requesting 16x MSAA.

Confirmation that the binaries the test was performed on was running with sdl2-compat:

LD_DEBUG=libs ./FishyHotel_linux 2>&1 | grep SDL3
   2598514:	find library=libSDL3.so.0 [0]; searching
   2598514:	  trying file=/lib/x86_64-linux-gnu/libSDL3.so.0
   2598514:	calling init: /lib/x86_64-linux-gnu/libSDL3.so.0
   2598514:	calling fini: /lib/x86_64-linux-gnu/libSDL3.so.0 [0]

ldd FishyHotel_linux | grep SDL
	libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f0df9d92000)

One note is that SDL_CaptureMouse(SDL_TRUE) does not seem to be honored currently via sdl2-compat.