Specific usage of Blueprint Struct crashes cooker

Found on 4.12.4, reproduced on 4.13.1, attached demo project.

I create a Blueprint Struct and give it some variables.
I create an Actor Component that contains the Struct as a variable.
I create two Actors and add that Actor Component to both of them.
I create another Actor that only contains a Blueprint Function which copies the Struct from one Actor to another.
Run a cook server using -run=cook -targetplatform=WindowsNoEditor -cookonthefly -integrate
Run the game using MyMap -game -filehostip=x.x.x.x
The cook process will crash while cooking the Actors. It may not crash if run again due to some of the assets being cooked so clear out the Saved/Cooked folder when retrying.

In the attached project:
Actor1 contains the Component and Struct - it’s referenced by MyGameInstance to force it to cook before the map.link text
Actor2 contains the copy Function and is placed in the map.
Actor3 contains the Component and Struct and is also placed in the map.
The bug occurs when cooking Actor1 then Actor2 then Actor3.

During the cook process:
Actor1 is cooked. It contains MyStruct so StaticAllocateObject() creates a new one and LinkExternalDependencies() calls PreLoad() and serializes it correctly.
Actor2 is cooked. It references MyStruct so StaticAllocateObject() finds and recreates the previous one, zeroing all its contents. LinkExternalDependencies() does NOT do anything further with MyStruct, does not call Preload() and leaves MyStruct in a zeroed state.
Actor3 is cooked. It contains MyStruct and ends up crashing in UScriptStruct::InitializeStruct() at the call to GetCppStructOps() because bPrepareCppStructOpsCompleted is false (from when Actor2 zeroed it).

If I add a node to the copy function to access the contents of MyStruct, such as a ‘break structure’ and then ‘print text’ one of its variables, then LinkExternalDependencies() finds that via Node->HasExternalDependencies() and correctly calls Preload() and initializes the MyStruct in Actor2 and the crash goes away.

So it looks like that in one place, Actor2 has an import reference to MyStruct causing StaticAllocateObject() to create one, but then does not finish off initializing it by calling Preload() (or whatever it needs to do). This leaves the partially constructed MyStruct to crash when Actor3 is cooked.

Yeah, cooking and packaging works fine - it’s only CookOnTheFly where it breaks.

Hey ,

I packaged your project as is and didn’t have any issue(s). I am able to run the CookCrash.exe and everything seems to work fine.

Is there anymore information that you can give me regarding your issue?

Thanks,

Hey again,

I tried again with these settings:

110545-502487_cook.png

Everything went fine; no crash(es).

Is there anything else you can tell me about your setup?

Thanks.

Here’s a step-by-step of my repro case…

Go to GitHub and get 4.13.1 as a zip file, unzip it to HD.
Unzip my demo project to the same place.

Run Setup.bat

Run GenerateProjectFiles.bat

Open the solution in VS2015 (we’re still using Update 1)

Set build configuration to Debug Editor + Win64.

Right-click on CookCrash project and Build Only CookCrash

Open up a command prompt at that location.

Run the CookOnTheFly server:
start “” Engine\Binaries\Win64\UE4Editor-Win64-Debug-Cmd.exe CookCrash -run=cook -cookonthefly -targetplatform=WindowsNoEditor -integrate

Run the game:
CookCrash\Binaries\Win64\CookCrash-Win64-Debug.exe MyMap -game -filehostip=xx.xx.xx.xx

On mine, the cook server crashes…the command prompt just disappears (but you can attach a debugger to it beforehand to catch it). The game stops saying it’s unable to load the map but that’s because it’s lost connection to the cook server.

The cook server crashes ‘silently’, doesn’t assert or show any dialogs so you may not be aware it’s crashed, especially if you’re running it from within the editor/frontend.

Nothing special about my setup, just Win64 8.1. Got 50 people here who were seeing the same crash with our game before I managed to reduce it down to the repro case.

Are you trying to build while running the program through Visual Studio?

I don’t quite understand that question. I build the executables in VS and then run them from the command prompt. They don’t exist until the build has finished since I’m building from new source in a new folder.

Sorry, I meant, are you debugging the program when building the project? with Local Windows Debugger or New Debug Instance?

It doesn’t seem so. I’ll try again on my end.

Sorry, mixed up building code and building data.

I start up the cook server, use Debug/Attach in VS to attach to it and then run the game. VS catches the crash.

Don’t forget to delete /Saved/Cooked each time you try it.

Just out of curiosity, why are you using this work flow? There are a couple other ways to package your project that don’t require the command line, one is via the UnrealFrontend.exe and the other is through the editor, File → Package → Windows ->Windows64.

I will still investigate what you are describing, I just wanted to let you know that there is another option.

To followup, I think this is the reason you are having an issue:

-cookonthefly	
Specifies that the cooker be started in server mode. This will launch a server which waits for a game to connect and then serves the cooked data as needed. When this option is used, the game requires -filehostip= specified on its command line so it can connect with the server.

Are you setting the “filehostip=” when you run the command?

Yes - as stated in my first post and again in my repro steps.

This is just one workflow we have where the artists/designers/production can grab the latest executables and assets from Perforce, run a cook server and the game without having to package anything or run the editor.

Most days and most of the time, we’re all in the editor.

This workflow just happens to be the one that shows up the crash bug.

Sorry about that, the x.x.x.x blended right in.

I am still investigating. I’ll let you know what I find.

Thanks.

Hey ,

Thanks for the feedback. I was able to reproduce the issue and have submitted a bug report regarding it. You can follow it here:

https://issues.unrealengine.com/issue/UE-37284