gs_audio: Use-after-free crash on exit

[ghost]

Gunslinger apps occasionally segfault when closing. It's not really a big deal since the program is already exiting, but I know users in the Discord have mentioned it before so I thought it should be officially reported.

Tested on Linux w/ GCC.

Address Sanitizer says this crash happens when ma_audio_commit accesses the audio subsystem after the engine instance has been freed.

gunslinger/impl/gs_audio_impl.h

Lines 449 to 453 in fc25815

	for (
	gs_slot_array_iter it = gs_slot_array_iter_new(audio->instances);
	gs_slot_array_iter_valid(audio->instances, it);
	gs_slot_array_iter_advance(audio->instances, it)
	)

gunslinger/impl/gs_platform_impl.h

Lines 1397 to 1398 in fc25815

	// Free engine
	gs_free(inst);

GDB backtrace:

#0  0x00005555555699fe in ma_audio_commit (device=<optimized out>, output=0x7fffe465edc0, input=<optimized out>, frame_count=440) at ../../third_party/include/gs/impl/gs_audio_impl.h:449
#1  0x000055555564d430 in ma_device__on_data (pDevice=pDevice@entry=0x555555c189d0, pFramesOut=pFramesOut@entry=0x7fffe465edc0, pFramesIn=pFramesIn@entry=0x0, frameCount=frameCount@entry=440)
    at ../../third_party/include/gs/impl/../external/miniaudio/miniaudio.h:9948
#2  0x000055555565ee3f in ma_device__read_frames_from_client (pFramesOut=0x7fffe465edc0, frameCount=440, pDevice=0x555555c189d0) at ../../third_party/include/gs/impl/../external/miniaudio/miniaudio.h:9976
#3  ma_device_main_loop__pulse (pDevice=0x555555c189d0) at ../../third_party/include/gs/impl/../external/miniaudio/miniaudio.h:21417
#4  0x0000555555578e00 in ma_worker_thread (pData=0x555555c189d0) at ../../third_party/include/gs/impl/../external/miniaudio/miniaudio.h:30577
#5  0x00007ffff7c72299 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007ffff7b99053 in clone () from /usr/lib/libc.so.6

Relevant address sanitizer output:

=================================================================
==6555==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000000030 at pc 0x55978997b005 bp 0x7fbcffe47050 sp 0x7fbcffe47040
READ of size 8 at 0x608000000030 thread T1
    #0 0x55978997b004 in ma_audio_commit ../../third_party/include/gs/impl/gs_audio_impl.h:433
    #1 0x559789b8fece in ma_device__on_data ../../third_party/include/gs/impl/../external/miniaudio/miniaudio.h:9948
    #2 0x559789bbd489 in ma_device__read_frames_from_client ../../third_party/include/gs/impl/../external/miniaudio/miniaudio.h:9976
    #3 0x559789bbd489 in ma_device_main_loop__pulse ../../third_party/include/gs/impl/../external/miniaudio/miniaudio.h:21417
=================================================================
0x608000000030 is located 16 bytes inside of 96-byte region [0x608000000020,0x608000000080)
freed by thread T0 here:
Direct leak of 270387 byte(s) in 59 object(s) allocated from:
    #0 0x7fbd0b49a0e9 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:123
    #1 0x55978995f3ff in main ../../third_party/include/gs/impl/gs_platform_impl.h:1398
    #0 0x7fbd0b49a639 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154

    #1 0x7fbd05cff9e3  (/usr/lib/libnvidia-glcore.so.460.56+0xd739e3)

[MrFrenik]

I'm currently re-writing large portions of the audio subsystem right now, because it's had issues like this for a while. I'll keep this open, so know that it's actively being worked on.