Ios crash on launch arm64 distribution build

Hello,

I’m building on Mac, with UE 4.11.2.

When I package my project for Ios 8, distribution, armv7: it runs well.

When I package it with the same settings but I add arm64 checkbox (which is mandatory for Apple): the app crashes on launch.

I’m testing on iPad Pro and iPad Air 2.

I’m getting this log from Xcode debugger on launch:

crash log

So it’s crashing here:
std::__1::basic_string, std::__1::allocator >::~basic_string()

I’m now trying to address the problem. Any advice would be great.

Thank you.

Hey Spiez,

  • Do you have any other logs that you could provide? Perhaps the error output logs from the engine?
  • Have you been able to reproduce this crash on any project you attempt?
  • Do you know the reproduction steps?
  • What device are you using, since it runs well on the iPad Pro and iPad Air 2.

Please provide as much information as possible in order to try and replicate the issue.

Thanks!

Now I did more tests. It runs well on every device I’ve tested in every configuration (even in arm64) when built on Development configuration. When built on Shipping (production) configuration, it works well on armv7 but not on arm64. Maybe I can have better chances building remotely from a PC? Maybe it’s a problem with libc++? or libstdc++?

When I retrieve the Container of the app, the Logs folder is not even created. So I don’t have an UE log for this, I think it crashes before creating any UELog.

To reproduce I package the project with C++ code with a Mac with 10.11, Xcode 7.3. I’m using the File->Package->iOS command on UE4. I’ve not yet tested this with another project.

I’ve built from windows and I get the same error. I’m thinking this could be related to this:

Now I’m trying to reduce clang++ optimization level to -o0, maybe that’s causing this misaligment. I will report back if I find anything.

UPDATE:
Switching to -o0 didn’t change anything. Now I’m testing with “Include Debug Files” to see if I get a better log when debugging from xcode.

Note: I’m usign libc++ std library with another thirdparty library.

I know this is not a critical bug in the engine, but we really need Epic’s support on this issue since our product is really close to release and we are currently blocked by this issue.

Currently I’m trying to spot the change between development and shipping that is allowing the latter to work and modify the engine so that also the shipping build works as the development build on arm64. The codebase is enormous and I would like to know where to look at.

Please help us! Thank you.

OK, I’ve solved this issue (after 4,5days of debugging).
If anyone ever encounters a problem with the C++ standard library and arm64, the fix for me was to enable symbols in UnrealBuildTool IosToolChain.cs. Commenting out the lines involving bStripSymbolsOnIOS.

This will make a very large executable, maybe you can change how much stripping is done (I believe we use -a). Maybe in a pinch you could change the command line to remove the -a, and do normal stripping, and see if it works, but without resulting in a massive executable.

We heard back from another that using the -x command line parameter to strip solved the problem and added only a small amount of additional overhead.

The change is to make the Arguments line look like this:

StripProcess.StartInfo.Arguments = "-x \"" + Target.OutputPath + "\"";

Hello my friend, I’m going through a similar problem. Could anyone help me solve this problem? Please see my problem post below … thank you so much

Hello my friend, I’m going through a similar problem. Could anyone help me solve this problem? Please see my problem post below … thank you so much

I fix it by using this way above and generating the project again.

We solved the same problem with this “-x” parameter on all ios devices except iPhoneXS and iPhoneXS . It is easy to reproduce the problem on these two devices, just create an empty project, and put the following code in YourProjectModule::StartupModule, and then package it with arm64, shipping. By the way, we use Xcode 10.0, engine version 4.18.3. When launched, you would see a warning “LogMemory: Warning: Attempting to free a pointer we didn’t allocate!” from FreeInternal() in MallocBinned.cpp. After this warning appears, we would be facing random crash in our game. It is such a headache that nearly driven us crazy!

        UE_LOG(LogTemp, Warning, TEXT("Test 1"));
    	{
    		std::stringstream ss;
    		ss << " This is a test string from ss " << std::endl;
    		UE_LOG(LogTemp, Warning, TEXT("%s"), 
                UTF8_TO_TCHAR(ss.str().c_str()));
    	}
    
    	UE_LOG(LogTemp, Warning, TEXT("Test 2"));
    	{
    		std::string s;
    		s = " This is a test string from ss ";
    	}
    
    	UE_LOG(LogTemp, Warning, TEXT("Test 3"));
    	{
    		std::stringstream ss;
    		ss << " This is a test string from ss " << std::endl;
    
    		FString s = UTF8_TO_TCHAR(ss.str().c_str());
    	}
    
    	UE_LOG(LogTemp, Warning, TEXT("Test 4"));
    	{
    		std::stringstream ss;
    		ss << " This is a test string from ss " << std::endl;
    	}

Hi ,

on 2018-12-25, we find a new problem.

Your way can not fix on iphone XR , although it works for many ios devices.

Any other advices ? Appreciate !

We ran into this problem too. Did anybody find a fix that will work with the latest iphones?

Hello, guys.
I’ve got the same problem and only in Shipping mode. I’ve changed the bStripSymbols in IosToolChain.cs, but IPA on the ios device still crashes, like there were no changes.
How did you rebuild *.cs source files of the unreal engine after changing them?

Protobuf is also crashed on UE 4. Why does UE 4 not support iOS dynamic library which can fix this issue ?

FYI, maybe its fixed now. But I found the issue was related to the new/delete operators being overloaded differently in core UE. I forget exactly, but I think it may have been due to debug/shipping versions mismatch between engine and a library. Or it was using the wrong std library. So basically an object was being deleted and unreals memory management system did not know, which eventually will crash if it uses it.