Project Corruption on Mac

I have had frequent problems with various projects being corrupted on Mac OSX 10.9 and 10.10 using UE4 Editor 4.6.x and now 4.7.5. It has happened on ShooterGame example, on simple test projects and now on a project based on FPS Wiki Tutorial. I am using XCode 6.2 on a Mac Pro with 22GB of RAM, a 5770 video card and Mid 2010 2x2.4 Ghz Quad Core Xeon.

I believe I’ve isolated this to class changes in C++. I can recreate it in my current test project by adding code, compiling, running one or many successful tests, then closing project, and attempting to reopen it. I can easily believe that I am creating code that is incorrect in some manner (especially in this case because I am experimenting with creating dynamic TArrays of structs), but fact that editor allows project to work, then save, yet will not permit it to be opened again, seems like it could be a bug. With my current tests, it seems too consistent to be a memory error on my computer. test environment is trivial and has only rudimentary objects and textures (see Wiki FPS Tutorial)

issue shows up on reopening project by editor aborting with a dump. dump always lists whatever class I was working on as culprit in creating a memory error. I can correct corruption by loading XCode and double clicking on .xcodeproj in UnrealProjects/Projectname directory, loading it, removing some code, running a Clean, then a Build and exiting XCode. Then I remove .dylib files in Binaries/Mac directory, restart project and it will load after it recreates .dylib file.

While my code may cause problems, I have recreated this with adding a simple display into a class, testing it, saving it, then attempting to reload project. My question is, is this a bug of UE4 or is it normal to need to have perfect code in previous session to avoid being unable to load project on next invocation of editor?

I have sent several crash reports on this over last month.


As requested, here is an example of code that does this. I removed UE4 macro struct version I was experimenting with because it vastly complicated issue. Here is simpler, hopefully good code that still reproduces problem. I have made simpler code that also did same thing.

In project/Engine h file, I place this struct definition:

struct FInventoryDefinition {
    int32 IType;
    FString IName;

Then in GameMode.cpp, I place following:

at top:

FInventoryDefinition Inventory[5];

at bottom:

bool AFPSGameMode::LoadInventory() {
    Inventory[0].IName="Machine Gun";
    GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Green, TEXT("Inventory Loaded"));

In constructor, I place this:

if(LoadInventory()) {
   GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Green, TEXT("Inventory Reported Okay"));

I compile using Compile button in editor. It completes with a clean compile log and I Play one or more times. code seems to work each time. I then close Unreal Editor and wait a few minutes. Open .uproject file and get a crash with a dump that begins like this:


Generating report for minidump

Application version 4.7.5-2503383+++depot+UE4-Releases+4.7
 ... built from changelist 2503383
 ... based on label ++depot+UE4-Releases+4.7

OS version
Running 8 x64 processors
Exception was "SIGSEGV: invalid attempt to access memory at address 0x78d"

Source context from ""


AFPSGameMode::AFPSGameMode(FObjectInitializer const&) Address = 0x13d460bfa [/Users/myusername/Documents/Unreal Projects/FPSProject 4.7/Source/FPSProject/FPSGameMode.cpp, line 17] [in UE4Editor-FPSProject-8591.dylib]
UClass::CreateDefaultObject()  Address = 0x105820341 (filename not found) [in UE4Editor-CoreUObject.dylib]
ProcessNewlyLoadedUObjects()  Address = 0x1059a98aa (filename not found) [in UE4Editor-CoreUObject.dylib]
TBaseStaticDelegateInstance<void ()>::ExecuteIfSafe() const  Address = 0x1058517c7 (filename not found) [in UE4Editor-CoreUObject.dylib]
TBaseMulticastDelegate<void>::Broadcast() const  Address = 0x1050a6ad8 (filename not found) [in UE4Editor-Core.dylib]
FModuleManager::LoadModuleWithFailureReason(FName, EModuleLoadResult&, bool)  Address = 0x10526a720 (filename not found) [in UE4Editor-Core.dylib]
FModuleDescriptor::LoadModulesForPhase(ELoadingPhase::Type, TArray<FModuleDescriptor, FDefaultAllocator> const&, TMap<FName, EModuleLoadResult, FDefaultSetAllocator, TDefaultMapKeyFuncs<FName, EModuleLoadResult, false> >&)  Address = 0x10a3c1bda (filename not found) [in UE4Editor-Projects.dylib]
FProjectManager::LoadModulesForProject(ELoadingPhase::Type)  Address = 0x10a3d21ce (filename not found) [in UE4Editor-Projects.dylib]
FEngineLoop::LoadStartupModules()  Address = 0x104ffd588 (filename not found) [in UE4Editor]
FEngineLoop::PreInit(wchar_t const*)  Address = 0x104fe8771 (filename not found) [in UE4Editor]
GuardedMain(wchar_t const*)  Address = 0x104ff2b64 (filename not found) [in UE4Editor]
-[UE4AppDelegate()  Address = 0x1050017c3 (filename not found) [in UE4Editor]
-[FCocoaGameThread()  Address = 0x105150278 (filename not found) [in UE4Editor-Core.dylib]
__NSThread__main__()  Address = 0x7fff97ba290a (filename not found) [in Foundation]
_pthread_body()  Address = 0x7fff946e7268 (filename not found) [in libsystem_pthread.dylib]
_pthread_body()  Address = 0x7fff946e71e5 (filename not found) [in libsystem_pthread.dylib]
thread_start()  Address = 0x7fff946e541d (filename not found) [in libsystem_pthread.dylib]

Hi ,

Can you post code you added to your new class, and type of class you made, so we can recreate it here? Additionally, it would be helpful to see Crash Reporter dialogue that pops up after crash, and crash log from project. Thanks!

, I provided this above with exception of log (which I don’t know where to find). I hope I stated clearly enough that code is likely very wrong (since repeated executions continue to add to TArray between "Play"s, something really wrong there to have data persist over executions), but issue is not being able to get back into project once it’s closed. I’ve had this with nearly every project I’ve worked on where I alter any C++ code. My son, using a nearly identical system, only works on blueprints, does no XCode work and has not had this issue. I also forgot to mention that everything we do is OS X only, no IOS.

Hey -

When adding USTRUCT() code you provided above to a custom Engine class there are compile errors relating to ItemType and IType variables. Additionally, in GameMode.cpp there are compile errors caused by FInventoryDefinition. Are there other includes that need to be added or other classes necessary for references?

Interesting. I received no compile errors. I removed all USTRUCTS, GENERATED_STRUCT_BODY, and UFUNCTION calls as they were something I put in to try and get around problem, not part of original issue. After doing so, issue persisted until removing call to LoadInventory(). Again, I had no compile errors and at this point, editor will open (after rebuilding in XCode and deleting files/directories as mentioned originally).

This makes it sound like I should be getting compile errors but for some reason, am not. Oddly, I can load project now, add inventory load call back in and it “works”, until I close editor and try to start again. Why would I not get compiler errors you are getting? I don’t get them whether using Compile button in editor or doing an external build with XCode.

On second reading of your reply, I realized I didn’t answer your question, but yes, it needed a #include of engine.generated.h if using USTRUCT etc. I apologize for not including that. better solution is as my last reply, remove all UE4 macros as they have no purpose here.

I dramatically simplified code to recreate my problem. I hope it’s not inappropriate to revise question that much, but it would have made it much longer. At this point I question if you can recreate this problem since it should be glaring if it was happening to everyone on an OSX UE4 implementation.

I wanted to update this. I found that since going to 4.7.5, I can’t make any change to AGameMode, ACharacter, or AActor classes without causing this project corruption. On 4.6, it only happened sometimes. I would think you would need to look at what editor generated for an xcodeproj to see how this could have occurred?

I believe I have discovered source of problem. If I include a display in any constructor for any of classes, that does a display, or a call to a function that does a display, e.g.,

GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Green, TEXT("some screen display"));

it will work until I close project. Then, on reopening project, it will be corrupted. Does this seem like a timing issue?

Hey -

I just wanted to confirm repro steps to make sure I’m following same setup that you’re using:

First you create a new class based on Engine and add:

struct FInventoryDefinition {
     int32 IType;
     FString IName;

Then you add a new class based on GameMode. When you say that you add FInventoryDefinition Inventory[5]; at top, what exactly do you mean?


bool AFPSGameMode::LoadInventory() {
     Inventory[0].IName="Machine Gun";
     GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Green, TEXT("Inventory Loaded"));

is added at bottom of source file, correct? Is there anything other than LoadInventory() function that has to be setup in header file for GameMode? Let me know if I’ve forgotten a step or left something out.

What I found (see last comment above, made 2 days ago), is that problem can be created merely by adding GEngine->AddOnScreenDebugMessage to constructor of AGameMode class or to any function that it calls. It takes only a single line for me to reproduce it (as shown in other comment). It was unnecessary to have arrays or even function calls. Once I remove AddOnScreenDebugMessage functions from any of constructors, problem goes away. If you like I can provide exact source code, but it is just as other comment shows and describes. I would be very interested to know if you can put a debug message in in constructor, so I can tell if it’s actually something else causing UE 4 Editor to fail.

Now that I realize this, I realize that it’s why ShooterGame would corrupt projects too. I had always included debug messages where I had added code.

Hey -

If call to GEnine is being made before renderer is created then that can cause problems when CDO is created when project is opened. This would coincide with what you said about making call to GEngine in constructor. Let me know if you making call to LoadInventory() and GEngine->AddOnScreenDebugMessage() on BeginPlay() rather than inside constructor still causes corruption issue. Additionally, you may want to add an if(GEngine) check to make sure that GEngine is not null.


Yes, if call is done from BeginPlay, it works fine. project does not corrupt then.

I see that this is an answer to issue, and I voted it up as answered now, but I was hoping someone at Epic would look at making editor more resilient. I think biggest issue here is that everything works fine when you save and close, giving a false sense of security that all is well, but then that project can’t be reopened, and without a lot of head scratching, would be considered lost. Thanks for specifically responding to my issue.

Because certain parts of engine have to be created/loaded for calls to engine to be successful it would be best to test that it exists before using it. Adding if(GEngine) prior to GEngine call would only call that code if GEngine has already been created.

If we added a message to UBT to warn when GEngine is used warning would pop up every time a call to GEngine is made which would also be frustrating.

I understand, but my thought is that there must be some way to keep from aborting project load, and instead flagging error. As it is, there is no logical or documented way to get project back once you have made this mistake.

I will test if having if(GEngine) would make a difference in whether project would reload or not, I can’t imagine it would unless a project object code were somehow executed during load, and that would not make sense to me if it did that sort of thing. It may be my own misunderstanding about what has to occur during project load, but anything that aborts a load and renders project unchangeable, would seem to be something that should be avoided by editor.

I’m not laboring this further! I know how to not have this one happen in future. I’m just speculating about what would help a noob such as me not spend weeks trying to figure out something like this.