[macOS] Fails to launch: Task Manager

[shinra-electric]

Describe the bug
Game fails to launch on macOS when the source code folder is not present.

To Reproduce
I usually create an app bundle for OpenXRay using this script.
After the app is bundled, the script will delete the xray-16 source code folder.

When trying to launch the game, it will fail to launch because it cannot find xray-16/src/xrCore/xrDebug.cpp, which no longer exists.

Additional information:
xrCore.dylib is present in the app bundle, and the xr_3da executable is able to find it there.

Terminal log:
Terminal Saved Output.txt

Desktop:

• OS: macOS 15.1 Sequoia
• Building directly from dev branch (11th November 2024)

[Xottab-DUTY]

No, xrDebug.cpp is not the crash reason. I'm quite not sure what the real reason is.

Do you have the game files in /Users/user/Library/Application Support/GSC Game World/S.T.A.L.K.E.R. - Call of Pripyat/ folder?
It's a hardcoded path, where the game should be.

[shinra-electric]

Do you have the game files in /Users/user/Library/Application Support/GSC Game World/S.T.A.L.K.E.R. - Call of Pripyat/ folder? It's a hardcoded path, where the game should be.

Yes, the script copies over the data folders if it detects them.

[Xottab-DUTY]

objc[864]: Class SDLApplication is implemented in both /opt/homebrew/Cellar/sdl2/2.30.9/lib/libSDL2-2.0.0.dylib (0x1039a46c8) and /Applications/Games/OpenXRay.app/Contents/libs/libSDL2-2.0.0.dylib (0x10332c6c8). One of the two will be used. Which one is undefined.

Hmm, if it's not the problem with files, then this might also be related. What if you delete /Applications/Games/OpenXRay.app/Contents/libs/libSDL2-2.0.0.dylib so that the engine would use system's dylib?

[shinra-electric]

Hmm, if it's not the problem with files, then this might also be related. What if you delete /Applications/Games/OpenXRay.app/Contents/libs/libSDL2-2.0.0.dylib so that the engine would use system's dylib?

I know the reason for this warning, but it's usually benign.

I built it again, but just normally without making a bundle and keeping the source folder. The error still occurs.

Here is the terminal output:
OpenXRay_Output_CLI.txt
Sorry, use this one instead:
OpenXRay_Output_CLI2.txt

I included the CMake config and build output, just in case there is anything relevant there.

[Xottab-DUTY]

At first I didn't paid attention to this:

stack trace:

xrDebug::GatherInfo(char*, unsigned long, ErrorLocation const&, char const*, char const*, char const*, char const*)
xr_terminate()
std::__terminate(void ()())
std::terminate()
std::__1::condition_variable::__do_timed_wait(std::__1::unique_lockstd::__1::mutex&, std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l>>>)
TaskManager::TaskWorkerStart()
void std::__1::__thread_proxy[abi:ne180100]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, std::__1::thread Threading::RunThread<void (TaskManager::)(), TaskManager>(char const*, void (TaskManager::&&)(), TaskManager&&)::'lambda'(void (TaskManager::&&)(), TaskManager&&), void (TaskManager::)(), TaskManager>>(void*)
7 libsystem_pthread.dylib 0x0000000192af32e4 _pthread_start + 136
8 libsystem_pthread.dylib 0x0000000192aee0fc thread_start + 8

Seems like some problem with our task manager.
Will try to investigate and I hope that I it's possible for me to fix it (I don't have any Mac 🙁)

[Xottab-DUTY]

@shinra-electric, can you run it under the debugger (e.g. GDB)?

[shinra-electric]

@shinra-electric, can you run it under the debugger (e.g. GDB)?

GDB doesn't run on Arm. What would be a good alternative?

[Xottab-DUTY]

@shinra-electric, can you run it under the debugger (e.g. GDB)?

GDB doesn't run on Arm. What would be a good alternative?

Maybe LLDB?

[shinra-electric]

I opened the executable in Xcode, which uses lldb. Here is the log:

openxray_lldb_output.txt

[Xottab-DUTY]

It looks that it isn't easy to solve. I'm not sure how.
After looking on the internet, it seems like a macOS bug with C++17 support, not ours.

Help is wanted and appreciated!