Segfault from Mix_CloseAudio()

[seisatsu]

I am experiencing a segfault on exit again. It looks like it's been around for quite a few commits.

Currently, Mix_CloseAudio() is commented out in our code as a workaround. We should concurrently investigate if there are any unwanted consequences from this besides the memory being held a bit longer on engine shutdown.

[seisatsu]

Looks like it's originating from Mix_CloseAudio(). Didn't we have trouble with this before? This is that Linux-specific bug isn't it.

[pmer]

If you install debug symbols for SDL2_mixer you can run Driftwood inside a debugger and find out where it's crashing.

[seisatsu]

I assume it's related to #70, but on my current system, the commit from back then that fixed it still segfaults. It must be somewhat dependent on the system running it. Installing debugging symbols gave little insight.

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x00007fffd807b210 in ?? ()
(gdb) bt
#0  0x00007fffd807b210 in ?? ()
#1  0x00007fffebdc3c5d in close_music () at music.c:939
#2  0x00007fffebdc2331 in Mix_CloseAudio () at mixer.c:1235
#3  0x00007ffff5edff0e in ffi_call_unix64 () from /usr/lib/libffi.so.6
#4  0x00007ffff5edf87f in ffi_call () from /usr/lib/libffi.so.6
#5  0x00007ffff60f31b5 in _ctypes_callproc () from /usr/lib/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so
#6  0x00007ffff60ed466 in ?? () from /usr/lib/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so
#7  0x00007ffff796b3a9 in _PyObject_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#8  0x00007ffff7a24ada in ?? () from /usr/lib/libpython3.6m.so.1.0
#9  0x00007ffff7a27857 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#10 0x00007ffff7a23def in ?? () from /usr/lib/libpython3.6m.so.1.0
#11 0x00007ffff7a24b85 in ?? () from /usr/lib/libpython3.6m.so.1.0
#12 0x00007ffff7a27857 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#13 0x00007ffff7a23def in ?? () from /usr/lib/libpython3.6m.so.1.0
#14 0x00007ffff7a24b85 in ?? () from /usr/lib/libpython3.6m.so.1.0
#15 0x00007ffff7a27857 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#16 0x00007ffff7a23def in ?? () from /usr/lib/libpython3.6m.so.1.0
#17 0x00007ffff7a24b85 in ?? () from /usr/lib/libpython3.6m.so.1.0
#18 0x00007ffff7a27857 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#19 0x00007ffff7a247d6 in ?? () from /usr/lib/libpython3.6m.so.1.0
#20 0x00007ffff7a24d2e in PyEval_EvalCodeEx () from /usr/lib/libpython3.6m.so.1.0
#21 0x00007ffff7a24d5b in PyEval_EvalCode () from /usr/lib/libpython3.6m.so.1.0
#22 0x00007ffff7a21ccd in ?? () from /usr/lib/libpython3.6m.so.1.0
#23 0x00007ffff79b38cd in _PyCFunction_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#24 0x00007ffff7a24ca2 in ?? () from /usr/lib/libpython3.6m.so.1.0
#25 0x00007ffff7a27857 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#26 0x00007ffff7a247d6 in ?? () from /usr/lib/libpython3.6m.so.1.0
#27 0x00007ffff7a2497f in ?? () from /usr/lib/libpython3.6m.so.1.0
#28 0x00007ffff7a24b85 in ?? () from /usr/lib/libpython3.6m.so.1.0
#29 0x00007ffff7a27857 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#30 0x00007ffff7a247d6 in ?? () from /usr/lib/libpython3.6m.so.1.0
#31 0x00007ffff7a24d2e in PyEval_EvalCodeEx () from /usr/lib/libpython3.6m.so.1.0
#32 0x00007ffff79951c5 in ?? () from /usr/lib/libpython3.6m.so.1.0
#33 0x00007ffff796b238 in PyObject_Call () from /usr/lib/libpython3.6m.so.1.0
#34 0x00007ffff7a6561d in ?? () from /usr/lib/libpython3.6m.so.1.0
#35 0x00007ffff7a668b7 in Py_Main () from /usr/lib/libpython3.6m.so.1.0
#36 0x0000555555554b30 in main ()

[pmer]

Well, the easy fix would be to not call Mix_CloseAudio in production builds. :)

[seisatsu]

Brilliant! I hope this doesn't have any unintended consequences aside from some memory being held for a few milliseconds longer at shutdown. We should look into that.

[pmer]

Looking at the code for these two functions: Mix_Quit() and Mix_CloseAudio(). Just a guess, but I wonder if we were calling them in the wrong order.

[pmer]

Might be fixed in #212.