[4.6] Crash on Import From 4.5.1

Unreal crashes when opening the copy of my project from 4.5.1.

I’ve done some of the other fixes found throughout the AnswerHub including deleting .ini files and also deleting the Widgets that seem to be causing fatal errors. (No, I didn’t close the timeline and yes, they’re all working great in 4.5.1)

I can get it to the point when deleting various widgets that the editor will load, but upon trying to load a map the following exception still occurs:

[2014.12.05-04.55.17:835][ 0]LogWindows:Error: Windows GetLastError: The operation completed successfully. (0)
[2014.12.05-04.55.38:468][ 0]LogWindows: === Critical error: ===
Fatal error: [File:D:\BuildFarm\buildmachine_++depot+UE4-Releases+4.6\Engine\Source\Runtime\CoreUObject\Private\Templates\Casts.cpp] [Line: 11]
Cast of nullptr to Blueprint failed

I’m having same issue if I run app in standalone viewer (works fine in editor)

Hello AGPStudios,

That error refers to a null pointer failing to cast to blueprint. I’d assume that that error is caused by one of the deleted widgets. Do you know which widget was causing the crash on import? That is, when the crash stopped appearing and allowed you to open the project in the editor, which widget had you just deleted?

Regardless of that, could you give me the crash report and dmp file for the original crash on import? This thread explains how to get them.

Hi ,

If you’re able to get into the editor with no problem, it’s unlikely that you have the same issue as AGPStudios. Could you make a new thread about your issue, with more information about the crash?

Thank you for getting back to me Jonathan.

The error pops up with or without the deleted widgets. I just get a variety of errors on the widgets due from excessive use of “remove from viewport”.

The dmp and everything else has already been included in the “logs.zip” attached to the original post.

Also to provide clarity to the issue, here are the logs & dump from an entirely fresh import without deleting any widgets. link text

Hey AGPStudios,

I’ve reported this crash internally and we’ll investigate it further.

Regards,

Jonathan

We actually had this come up as well and thankfully I was able to debug it enough that I think I understand the underlying issue and have a potential workaround for people that hit this.

The short answer is that I believe you (OP) have a cyclic dependency in Blueprint and when upgrading from 4.5 to 4.6 all BP asset references brought in by the engines basic need to startup (i.e. a game mode that you have set as the default globally, or the default map that is opening) will be recompiled; this is revealing what I believe is a bug in the regeneration/reinstancing of BPs [specific to cyclic dependency issues]. As a workaround I recommend trying to remove any “startup defaults” that force the engine to need to open any of your game assets on startup; this can be accomplished by making sure the following fields in your DefaultEngine.ini are commented out or omitted before you begin the migration:

[/Script/Engine.Engine]
GameUserSettingsClassName=/Script/MyGame.MyGameUserSettings
MyGamePlayerClassName=/Script/MyGame.MyGameLocalPlayer
UnrealEdEngine=/Script/MyGameEditor.MyGameEdEngine
EditorEngine=/Script/MyGameEditor.MyGameEdEngine

[/Script/EngineSettings.GameMapsSettings]
GameInstanceClass=/Script/MyGame.MyGameGameInstance
GameDefaultMap=/Game/Maps/MyGameEntry
ServerDefaultMap=/Game/Maps/MyGameServerMap
TransitionMap=/Game/Maps/MyGameTransitionMap
GlobalDefaultGameMode=/Script/MyGame.MyGameDefaultGameMode
GlobalDefaultServerGameMode=/Script/MyGame.MyGameDefaultServerGameMode

Any of the settings above may cause the engine to open the default map (you want it to be none/empty) and/or default game mode and begin to bring in references to assets in your game; this is what you are trying to avoid. Additionally if you have any native code that references your game assets (i.e. ConstructorHelpers::FObjectFinder) be sure to comment these out and compile before beginning the upgrade.

Assuming you cleared out any and all references of your game assets to the startup/default objects you should be able to upgrade to 4.6 and open your project…but here is where the real fun begins. Once you can open the editor you need to figure out which asset is “completely” broken; open and recompile BPs in your project one at a time until you get one that crashes the editor (for me it crashed before the BP would even open). Once you found the broken asset that wont open look at your log for output spew that looks like “Compile of failed. X Fatal issue(s)” where X is greater than 0; these are the assets that may be causing the cyclic dependency, re-run your editor and try to get the to compile. Rinse-repeat this process until you have your classes compiling; once you have all BPs compiling without a crash its safe to reimplement your ini settings and native references to assets. For me I had to actually delete the Blueprint from disk that had the cyclic dependency, then recompile related classes (albeit with errors due to the missing BP) to narrow down the nodes that cause these dependencies (i.e. Cast To ) and remove them. Unfortunately you could be searching for a needle in a haystack depending on the size of your project; to help with the optimism my project contained just over 500 Blueprints and I was able to fix everything in about 30 minutes.

So to OP, I hope the above helps.

To Epic in regards to what I believe is a bug in the reinstancing process:

Assuming cyclic dependencies are the problem; when the engine generates a list of classes that need to be regenerated/reinstanced the class which has a cyclic dependency will appear in this list more than once (FLinkerTables::ExportMap I believe; I assume a cyclic dependency because FBlueprintCompileReinstancer will be constructed multiple times for the same class in one run), the first will be reinstanced fine, however, this original class is what is in the linker table more than once and the duplicate pointers are not updated after the first one is reinstanced; so when the subsequent duplicates(duplicate pointer to the first one reinstanced) attempt to be reinstanced the CDOs have already been remapped to new offsets; this causes FObjectInitializer::InitProperties to try to copy property values from the CDO or the Archetype using offsets that have already changed…hit bad memory and you get the OPs callstack (i.e. UArrayProperty::CopyValuesInternal, Src/SrcArrayHelper points to bad memory; or UStructProperty::CopyValuesInternal Src points to bad memory, etc.).

Please, test if PR 682 applied on top of 4.6 fixes your issue.