Mac crash in PowerMeter::PowerMeter() com.apple.audio.units.Components

[Echelon9]

Trying to run CMake-derived fs2_open on OS X from the command line [0] reports the following call stack after a segmentation fault:

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.audio.units.Components    0x000000010f76369a PowerMeter::PowerMeter() + 74
1   com.apple.audio.units.Components    0x000000010f73a728 AUMixer3D::AUMixer3D(ComponentInstanceRecord*) + 286
2   com.apple.audio.units.Components    0x000000010f73ed79 ComponentEntryPoint<AUMixer3D>::Dispatch(ComponentParameters*, AUMixer3D*) + 113
3   com.apple.CoreServices.CarbonCore   0x00007fff8e5bfb0f CallComponentOpen + 46
4   com.apple.CoreServices.CarbonCore   0x00007fff8e5be9a7 OpenAComponent + 429
5   com.apple.CoreServices.CarbonCore   0x00007fff8e5be7f0 OpenComponent + 17
6   com.apple.audio.OpenAL          0x000000010cd56c63 Get3DMixerVersion() + 79
7   com.apple.audio.OpenAL          0x000000010cd5804d alcOpenDevice + 33
8   fs2_open_3_7_5_x64-DEBUG        0x000000010b967ddc openal_init_device(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) + 460
9   fs2_open_3_7_5_x64-DEBUG        0x000000010b95ca3d ds_init() + 813
10  fs2_open_3_7_5_x64-DEBUG        0x000000010b96e40f snd_init() + 95
11  fs2_open_3_7_5_x64-DEBUG        0x000000010b19107c game_init() + 748
12  fs2_open_3_7_5_x64-DEBUG        0x000000010b19e550 game_main(int, char**) + 160
13  fs2_open_3_7_5_x64-DEBUG        0x000000010b1a018f actual_main(int, char**) + 527
14  fs2_open_3_7_5_x64-DEBUG        0x000000010b1a0352 main + 34
15  libdyld.dylib                   0x00007fff8ca9c5ad start + 1

[0] $ ./fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG

System is Mac OS X 10.11.6 (15G31) and cmake version 3.5.2

[chief1983]

I can confirm that this is the same segmentation fault that I receive when running from wxLauncher, if I generate an error report I see the same call stack.

[jg18]

Possibly relevant. I did an otool -L on both 3.7.4 release and a fresh debug build of master (to be more precise, on the Unix executables inside the app bundles) to check what dynamic libraries the two builds are linked against.. Here's the differences between the two reports. Lines starting with < are dynamic libraries that are used with 3.7.4 but not 3.7.5, and vice versa for lines starting with >. The SDL differences make sense of course, but the rest make me wonder if the new FSO builds are missing required libraries, but my OS X programming knowledge is not enough to say for sure.

<   /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1404.46.0)
<   /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
<   /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)
<   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1258.0.0)
<   /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (compatibility version 1.0.0, current version 1.0.0)
<   /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
<   @rpath/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 12.4.0)
< FS2_Open 3.7.4.app/Contents/MacOS/FS2_Open 3.7.4:

>   @rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 5.0.0)
> fs2_open_3_7_5_x64-DEBUG.app/Contents/MacOS/fs2_open_3_7_5_x64-DEBUG:

I also find it interesting tha the stack trace mentions CarbonCore. I thought Carbon was deprecated and we'd moved away from it?

[jg18]

Also not sure if relevant, but when I double click on the 3.7.5 app directly in Finder to start FSO rather than use wxL, I get an error pop-up with the message "FreeSpace2/Fred2 cannot be run from a drive root directory!" Started looking into a bit but not much headway as of yet. I have FSO/FS2 set up in /Applications/FreeSpace2/.

[MageKing17]

@jg18 I updated your comment to make it a bit more readable; hope you don't mind.

Some of those libraries do seem kind of important; I'm a bit surprised at the "cannot be run from a drive root directory" error, though.

[asarium]

You could try adding the libraries manually to the XCode project generated by CMake to determine which library we need. Once we know that we can add that to the CMake configuration.

[jg18]

Didn't seem to help. I added all of the missing libraries/frameworks and it crashes in the PowerMeter constructor all the same. Besides, if required libraries were missing, wouldn't linking have failed due to unresolved symbols?

Another thought was that there might be a bug in Apple's OpenAL, so I tried swapping out Apple's OpenAL for my OpenALSoft dylib from a while back and got a different crash while FSO was attempting to compile a shader, although OpenAL successfully initialized which is progress. Debug log and massive stack trace linked below. Had to change log file extension to .txt to get GitHub to accept it.

fs2_open.log.txt

stack_trace.txt

No idea where the drive root directory issue is coming from, would have to look into that separately. Only happense when running the FSO app from Finder, not when using wxL.

EDIT: The line in the debug log starting with "buf:" was from me trying to debug the drive root directory issue.

[chief1983]

Built a build from right after the cmake merge, using 6646bf3. It doesn't crash with this issue. We should be able to bisect to where this breakage was introduced at least. The libraries thing I was referring to has more to do with the game not running when the build directory is not present. This issue happens even when it is present.

[chief1983]

7b352e511c569f91eb21327691654011fe12a711 is the commit that caused the PowerMeter breakage somehow. The memory tracking commit.

[Echelon9]

Time to crack out Valgrind.

[asarium]

@chief1983 and I tracked it down to our redefinition of the new operator. When that is removed the code works. My current theory is that OpenAL requires a specific alignment of the returned pointer that our implementation does not guarantee.

[chief1983]

If it really is just an expectation of the Apple OpenAL, we could try to see if we can guarantee that alignment, or finally get on with doing OpenALSoft full-time with OS X. It seems to get around the issue just fine.

[asarium]

Well, at far as I can tell, the alignment of new is not defined in the C++ standard. The pointers returned by vm_malloc are always aligned to 4 byte but the OpenAL code may need a memory address aligned to the pointer size.

[chief1983]

I just tried running an updated standalone on my Linux box, and got something that might be related to this.

scpuser@fileserver /usr/share/games/freespace2 $ ./fs2_open_3_7_5-DEBUG
FSO is running in legacy config mode. Please either update your launcher or copy the configuration and pilot files to '/home/scpuser/.local/share/HardLightProductions/FreeSpaceOpen/' for better future compatibility.
AL lib: (EE) alc_cleanup: 1 device not closed
ASAN:SIGSEGV
=================================================================
==10305==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000 (pc 0x00000000 bp 0xb1338800 sp 0xb12ff21c T3)
==10305==Hint: pc points to the zero page.

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
Thread T3 created by T0 here:

Not sure I remember how exactly to get much more info here. But, this machine has openalsoft 1.15.1 installed, not the original openal Linux library.

[asarium]

@chief1983 I opened a PR which adds a CMake option for enabling AddressSanitizer in clang builds. I tested FSO on my machine (Fedora 24) but I had no issues with that so the issue probably lies somewhere else.

[chief1983]

This was fixed with the removal of the memory tracker.