Packaged blank project crashes on launch when steam subsystem is enabled

Every time I try to launch my packaged game on MacOS, it crashes on launch with an error inside the Steam SDK. This used to work for me previously. I think the main thing that changed is that I upgraded my MacOS version to 13.4

To try and narrow it down, I created a blank C++ and just followed the UE documentation to enable barebones Steam subsystem support: Online Subsystem Steam Interface in Unreal Engine | Unreal Engine 5.1 Documentation. The blank project with those minimal changes encounter the same issue. If I package the game and try to launch it, it hits this crash:

[2023.07.16-23.26.52:168][  0]LogMac: === Critical error: ===
SIGBUS: invalid attempt to access memory at address 0x1358a0dbe

[2023.07.16-23.26.52:168][  0]LogMac: 0x24dfce74 libtier0_s.dylib!ThreadInterlockedIncrement()   [UnknownFile]) 
0x35374ea8 steamclient.dylib!CreateInterface()   [UnknownFile]) 
0x34857da4 steamclient.dylib!Steam_GSGetSteamID()   [UnknownFile]) 
0x34858228 steamclient.dylib!Steam_GSGetSteamID()   [UnknownFile]) 
0x35379318 steamclient.dylib!CreateInterface()   [UnknownFile]) 
0x24dfdba4 libtier0_s.dylib!SteamThreadTools::CThread::ThreadExceptionWrapper(void*)   [UnknownFile]) 
0x24df9654 libtier0_s.dylib!FreeCrashMemoryReserve()   [UnknownFile]) 
0x24df90c8 libtier0_s.dylib!FreeCrashMemoryReserve()   [UnknownFile]) 
0x24df9730 libtier0_s.dylib!CatchAndWriteMiniDumpExForVoidPtrFn()   [UnknownFile]) 
0x24dfdaf0 libtier0_s.dylib!SteamThreadTools::CThread::ThreadProc(void*)   [UnknownFile]) 
0x93b03fa8 libsystem_pthread.dylib!_pthread_start()   [UnknownFile]) 
0x93afeda0 libsystem_pthread.dylib!thread_start()   [UnknownFile]) 

This seems really serious. It reproduces 100% of the time and it reproduces in a blank UE5 project, so it seems unrelated to my code.

Running the packaged with a thread sanitizer shows that there’s a data race happening inside the Steam SDK right as it crashes, which seems relevant:

WARNING: ThreadSanitizer: data race (pid=76714)
  Read of size 8 at 0x0001464a6980 by thread T19:
    #0 AnsiGetAllocationSize(void*) <null> (CruiserCommand:arm64+0x1040b0dc0)
    #1 FMallocAnsi::GetAllocationSize(void*, unsigned long&) <null> (CruiserCommand:arm64+0x1040b10ec)
    #2 FMallocPoisonProxy::GetAllocationSize(void*, unsigned long&) <null> (CruiserCommand:arm64+0x104125584)
    #3 FMallocPoisonProxy::Free(void*) <null> (CruiserCommand:arm64+0x10412544c)
    #4 FMemory::Free(void*) <null> (CruiserCommand:arm64+0x1040f1a28)
    #5 operator delete(void*) <null> (CruiserCommand:arm64+0x103c457a4)
    #6 CreateInterface <null> (steamclient.dylib:arm64+0x10a1874)

  Previous write of size 8 at 0x0001464a6980 by thread T27:
    #0 AnsiMalloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040b0cd4)
    #1 FMallocAnsi::TryMalloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040b0ef4)
    #2 FMallocAnsi::Malloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040b0f44)
    #3 FMallocPoisonProxy::Malloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1041252b0)
    #4 FMemory::Malloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040f1920)
    #5 operator new(unsigned long) <null> (CruiserCommand:arm64+0x103c45494)
    #6 CreateInterface <null> (steamclient.dylib:arm64+0x10a1b88)

  Location is heap block of size 56 at 0x0001464a6980 allocated by thread T27:
    #0 malloc <null> (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x5bd54)
    #1 AnsiMalloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040b0ca8)
    #2 FMallocAnsi::TryMalloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040b0ef4)
    #3 FMallocAnsi::Malloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040b0f44)
    #4 FMallocPoisonProxy::Malloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1041252b0)
    #5 FMemory::Malloc(unsigned long, unsigned int) <null> (CruiserCommand:arm64+0x1040f1920)
    #6 operator new(unsigned long) <null> (CruiserCommand:arm64+0x103c45494)
    #7 CreateInterface <null> (steamclient.dylib:arm64+0x10a1b88)

  Thread T19 (tid=825411, running) created by thread T4 at:
    #0 pthread_create <null> (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x2fda8)
    #1 SteamThreadTools::CThread::Start(unsigned long) <null> (libtier0_s.dylib:arm64+0x116dc)
    #2 FSteamServerInstanceHandler::FSteamServerInstanceHandler(FSteamSharedModule*) <null> (CruiserCommand:arm64+0x101a8aea0)
    #3 FSteamServerInstanceHandler::FSteamServerInstanceHandler(FSteamSharedModule*) <null> (CruiserCommand:arm64+0x101a8a734)
    #4 FSteamSharedModule::ObtainSteamServerInstanceHandle() <null> (CruiserCommand:arm64+0x101a8a580)
    #5 FOnlineSubsystemSteam::InitSteamworksServer() <null> (CruiserCommand:arm64+0x1015c11e8)
    #6 FOnlineSubsystemSteam::Init() <null> (CruiserCommand:arm64+0x1015c0984)
    #7 FOnlineFactorySteam::CreateSubsystem(FName) <null> (CruiserCommand:arm64+0x1015e20e4)
    #8 FOnlineSubsystemModule::GetOnlineSubsystem(FName) <null> (CruiserCommand:arm64+0x1016230bc)
...

I tried reporting this to Steam (since this seems to be mostly a Steam issue), but they were very unhelpful and just told me that “We aren’t able to provide technical support for third-party software or tools, such as Unreal Engine”.

Hoping that by reporting it here I can either get some ideas on how to workaround this, or get some traction to get this fixed. As it is, it seems like packaging Steam games is just completely broken on the most recent release of MacOS.

Some other relevant information regarding versions:

  • MacOS: 13.4.1 (22F82)
  • Unreal Engine: 5.1.0 (also reproduces on 5.2.0)
  • Steam SDK: I tried both 1.53, 1.55 and 1.57 and each crashed in the same way.

I also have the blank project (with small modifications to enable Steam) available here: 39.47 MB file on MEGA.

Additionally, the packaged version of the game (which crashes on launch) is available here: 224.53 MB file on MEGA

I’m getting the exact same error on my M2 Mac. UE 5.2.1. C++ project.

Steam Version: 1689034492
Steam Client Build Date: Mon, Jul 10 9:01 PM UTC -08:00
Steam Web Build Date: Mon, Jul 10 1:48 PM UTC -08:00
Steam API Version: SteamClient020

Application runs perfectly if Steam client isn’t running. Crashes on init with Steam client running.

[2023.07.17-19.35.30:383][ 0]LogMac: === Critical error: ===
SIGBUS: invalid attempt to access memory at address 0x125874dbe

[2023.07.17-19.35.30:383][ 0]LogMac: 0x259b0e74 libtier0_s.dylib!ThreadInterlockedIncrement() [UnknownFile])
0x25348ea8 steamclient.dylib!CreateInterface() [UnknownFile])
0x2482bda4 steamclient.dylib!Steam_GSGetSteamID() [UnknownFile])
0x2482c228 steamclient.dylib!Steam_GSGetSteamID() [UnknownFile])
0x2534d318 steamclient.dylib!CreateInterface() [UnknownFile])
0x259b1ba4 libtier0_s.dylib!SteamThreadTools::CThread::ThreadExceptionWrapper(void) [UnknownFile])
0x259ad654 libtier0_s.dylib!FreeCrashMemoryReserve() [UnknownFile])
0x259ad0c8 libtier0_s.dylib!FreeCrashMemoryReserve() [UnknownFile])
0x259ad730 libtier0_s.dylib!CatchAndWriteMiniDumpExForVoidPtrFn() [UnknownFile])
0x259b1af0 libtier0_s.dylib!SteamThreadTools::CThread::ThreadProc(void) [UnknownFile])
0x8952ffa8 libsystem_pthread.dylib!_pthread_start() [UnknownFile])
0x8952ada0 libsystem_pthread.dylib!thread_start() [UnknownFile])

[2023.07.17-19.35.30:383][ 0]LogExit: Executing StaticShutdownAfterError
[2023.07.17-19.35.30:384][ 0]LogMac: Error: Error reentered: Fatal error: [File:./Runtime/Core/Private/Mac/MacPlatformMisc.cpp] [Line: 2421]
FMacPlatformMisc::GenerateCrashInfoAndLaunchReporter: posix_spawn() failed (13, Permission denied)

[2023.07.17-19.35.30:384][ 0]LogMac: Error: HandleError re-entered.
[2023.07.17-19.35.30:384][ 0]LogMac: FPlatformMisc::RequestExit(1)

After further testing, this issue seems to be specific to Apple Silicon native builds only. I updated your blank test project in UE 5.2.1 and tested a Universal build natively (crashes per above message) and with Rosetta forced on, which runs perfectly. It seems like either Epic or Valve has a bug in their native Apple Silicon libraries. For now, the workaround seems to be to use the Intel x64 builds until Epic/Valve sort this out.

1 Like

I’m also suffering from this issue – really hope it gets fixed soon.

Same issue here. Can confirm that running the game in Rosetta mode will no longer cause a startup crash