Regression: v1.80 -> 1.81 on FreeBSD

[ehaupt]

After updating from version v1.80 to v1.81, the following regression occurs:

ft2-clone /tmp/some.xm

The audio track plays normal but 'Error' box appears:

As soon as OK is pressed the player crashes:

Segmentation fault (core dumped)

Here is what I get from gdb:

$ gdb /usr/local/bin/ft2-clone 
GNU gdb (GDB) 14.1 [GDB v14.1 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/ft2-clone...
(No debugging symbols found in /usr/local/bin/ft2-clone)
(gdb) r
Starting program: /usr/local/bin/ft2-clone 
[New LWP 213570 of process 72069]
[New LWP 213571 of process 72069]
[New LWP 213572 of process 72069]
ALSA lib seq_hw.c:529:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory

MidiInAlsa::initialize: error creating ALSA sequencer client object.

Thread 4 received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
[Switching to LWP 213572 of process 72069]
0x00000000002e414c in ?? ()
(gdb) continue
Continuing.
Audio write: Invalid argument
[Detaching after fork from child process 72269]
[LWP 213571 of process 72069 exited]

Thread 4 received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x00000000002e414c in ?? ()
(gdb) bt
#0  0x00000000002e414c in ?? ()
#1  0x000000000027c7a1 in ?? ()
#2  0x000000000027cddf in ?? ()
#3  0x000000080045a2ad in ?? () from /usr/local/lib/libSDL2-2.0.so.0
#4  0x00000008004e83f9 in ?? () from /usr/local/lib/libSDL2-2.0.so.0
#5  0x0000000800518a75 in thread_start (curthread=0x804f70900) at /usr/src/lib/libthr/thread/thr_create.c:290
#6  0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdfbfc000

The following SDL versions are present on the system:

sdl2-2.30.1
sdl2_gfx-1.0.4
sdl2_image-2.6.3_5
sdl2_mixer-2.6.3_1
sdl2_ttf-2.20.2

[8bitbubsy]

Hi.

I can't trigger this crash on my Ubuntu test machine, but I found out that I had commented out the MIDI callback initialization code... Not that it should fix your issue, but it's pretty serious anyway. 🤣

[ehaupt]

Thank you for the update and for checking the issue on your Ubuntu setup!

To make things as easy as possible, I'm willing to set up a virtual FreeBSD image complete with a desktop environment and all the necessary tools for building and testing. This could help you avoid any extra setup on your side and jump straight into resolving the issue. If this sounds good to you, I can get everything ready and send it your way.

Just let me know if you’re interested, and I'll take care of the preparations.

[8bitbubsy]

I'm pretty sure the crash comes from the MIDI initialization thread. It even crashes on Windows XP, but works fine on Windows Vista and later. The reason I put the MIDI init in its own thread is because it can take several seconds on macOS. Maybe I should init it in the main thread, and only do the threaded solution (nasty) on macOS instead.

And yes, it may sound strange that it could come from the MIDI init thread when it worked in v1.80, but I think it's extremely sensitive to timing (the amount of code executed after thread is started).

Can you try to comment out line 235 to 247 (all of them) in current ft2_main.c from the github repo, and see if it still crashes when loading a module through the command line parameter?

EDIT: As this test requires the latest github code (not the code from "Releases"), make sure you try the code as is to make sure you're not trying to fix something that fixed itself. 😏

[ehaupt]

Can you try to comment out line 235 to 247 (all of them) in current ft2_main.c from the github repo, and see if it still crashes when loading a module through the command line parameter?

As usual, you were right :smile:

Commenting those lines from rev d12b46e 'fixes' the issue.

[8bitbubsy]

Argh... Almost tempting to remove MIDI support alltogether, as all it does is causing issues!

[ehaupt]

Definitely tempting.

[8bitbubsy]

OK I'll try the threaded method for macOS only, as a last resort. I haven't had any crashes on Mac so far, so maybe it's "safe" to do it there. I'll make a new version later today.

[ehaupt]

Sounds like a good plan! I really appreciate you taking the time. Looking forward to testing the new version.

[8bitbubsy]

Ok I have released v1.82 now. Could you test it out and see if the problem still persists?

[ehaupt]

I am happy to report that v1.82 has solved the problem. Thank you!