How can I narrow down the cause of this "=== Handled error: ===" in my pawn blueprint?

Development Programming & Scripting Blueprint
, , , ,
1

I get the attached “LogOutputDevice:Warning: === Handled error: ===” every time I open my project.

I can’t be sure when I introduced this issue into my blueprint (a Pawn BP, the one that comes with the Third Person template.) I thought I was keeping a good eye on the logs and messages, but I had never actually opened the Output Log, and was only watching my Message Logs. The attached text is what appears in my Output Log every time I open my project.

I finally became aware of the issue when I went to package my project. It will fail to package with an “Unknown Cook error” and contains the same stack dump as attached.

I can get this error to go away if I replace my Pawn blueprint with a fresh blank blueprint. Of course, my Pawn blueprint is tied to nearly the entire rest of my project, so I’d like to not just toss it out and start from scratch.

I tried to carefully start deleting bits of my Pawn blueprint, compile, save, and restart the editor until the error went away, taking note of what was deleted. I had deleted the entire Event Graph (leaving all my Custom Event nodes, with their execution pins empty, to hopefully reduce the warning/error complaints from other blueprints) and had deleted nearly all of my Functions and Variables, and all of my Event Dispatchers and Interface Functions before I was finally rid of the error. It had seemed to correspond with finally deleting two variables referencing a type of my own user defined structs.

However, to test this, I restored my entire Pawn blueprint, and then just deleted the struct variables and all their references (leaving the blueprint decimated, but compiling with the green checkmark) but upon the editor restart, the “Handled Error” from the attached was still present.

Given that my brute-force attempt to isolate the culprit failed, I am hoping you of the community can help me take a more intelligent or better informed approach. I’m happy to supplement with more log data, screenshots, or Uasset files if necessary.

link text

2

Your error is ensure function fail inside of blueprint compiler, it’s a failed condition that code inside engine expected, it happens in this point:

https://github.com/EpicGames/UnrealEngine/blob/dff3c48be101bb9f84633a733ef79c91c38d9542/Engine/Source/Editor/KismetCompiler/Private/KismetCompilerVMBackend.cpp#L980

By look of it it’s corrupted blueprint (by that i mean editor let produce some errorus data via some hole in code, and it is catched in compiler but compiler it self don’t know what it is), this might possibly be a bug, it also seems to as error in node linking (most likely some pin) as it is caused of DestinationExpression->AssociatedVarProperty being null. That is as much info i can get from this, to detect which pin data is corrupted you would need to debug in VS to see what data is in FBPTerminal* DestinationExpression argument when error happens and possibly other variables maybe some lower stack stuff too.

I will move this question to bug raport since it looks like a some bug, maybe someone from Epic will help you out

3

Thanks for the input, . You’ve given me a good idea where to start. I appreciate it!

I’ve got Visual Studio and have even added some very small bits of C++ to this project (Blueprint Library functions), so I’ll try to figure out debugging in Visual Studio. I’ll see if I can learn what FBPTerminal* DestinationExpression has to say about my pin data.

4

Hello oden_nauticus,

I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide a detailed list of steps on how to reproduce this issue on our end?
  3. Could you provide screen shots of any blueprints that may be involved with this issue?
5

, your advice helped me discover the offending node. Thank you. Your massive karma score is well-deserved.

However, this was not a bug on Epic’s part at all. This is simply a case of bad practices due to my incomplete understanding of computer science. I used a DecrementInt node and had passed it the output of a Select node, of which not every pin led to the instance of a variable. No wonder the Kismet Ensure function disliked this! After removing the DecrementInt node, my project now opens without the Error mentioned in my question post.

For those like me, inexperienced with the troubleshooting tools available, here is what I did to track down the node:

Using the error in my question post (and 's helpful confirmation of the code in question) in Visual Studio I set a breakpoint on the function at line 980 in KistmetCompilerVMBackend.cpp. If I knew this process better, I could probably have somehow filtered the breakpoint triggers down, but I quickly executed through the function breakpoints until I was able to tell it was iterating through the class I knew was at fault. Once there, I carefully executed through the nodes one by one until my error came up in the Visual Studio debugger Output window. I made note of all the info about the node in question (in particular, its EdGraphPin number, and the fact that it was a K2_Select node)

Then I loaded up my blueprint in the editor and searched out all the Select nodes and copy/pasted them into a text editor. I found the EdGraphPin number I collected from the debugger among the pasted text and used that info to find my node in my blueprint graph.

90393-badnode.jpg
90393-badnode.jpg1051×445 79.7 KB

6

Woo, good to see that you able to figure it out alone :slight_smile: It still is a bug since the error you got should never happen it’s actully place there to prevent potential instybilities from unpredicted behaviors. It means there errorus combination of nodes that blueprint designer don’t prevent it and/or compiler don’t properly inform user that it is wrong, insted it hits that ensure function giving cryptic error which you need to debug engine to understand. Now this will most likely be fix.

7

I’ve got the same problem with my project in 4.12.1, however it’s Blueprint only and I don’t know how to debug this with VS or somehow else. This shows up everytime I start the project. I actually thought it only showed up when packaging, but thanks to your thread I paid attention to the log when starting my project and it’s there like yours. Does anyone of you know a way to debug this?

8

Hi adipFTW,

I could be wrong (I am very much new to all of this), but I believe in order to narrow this down systematically, you will still have to get Visual Studio and set a breakpoint on line 1045 of KismetCompilerVMBackend.cpp, and step through the triggers like I did until you see your error in the log.

Luckily, Visual Studio 2016 Community is free and supported by UE4.

The other approach I see people take with these issues is to start a new empty
Blueprint project, and start migrating their Content over, one by one, until the error comes back, or they are fully migrated and have escaped the issue. If the error comes back, then just note which Uasset was migrated when the error returned, and you’ve at least narrowed it down to a single asset.

In my case, I already knew which Blueprint was at fault, it was just so big and gnarly that I didn’t know where to begin to look inside it. That is where the Visual Studio process helped me. It led me to the exact node that caused the issue.

9

Hey oden,

I was able to localize my problem! The main problem was, I didn’t know what ‘error’ to look for in Visual Studio, but since only one error showed up, I guessed that had to be the one and it was indeed! Just as you, my problem came from a select node leading into an IncrementInt node, however in my case all inputs were connected to variables.

http://puu.sh/pmZ9b/5babab58d2.jpg

EDIT: Using a SelectInt node with the following setup did not result in that error:

http://puu.sh/pmZXw/54555f76fc.png

10

Nice job, adipFTW!

I wonder why these nodes don’t work this way… I’m just an animator dabbling in arcane computer science topics I don’t understand properly.

If I had to guess, I would say that it must have to do with ‘passing by reference.’ Node pins that are diamond shaped are variables that are passed “by reference” (a pointer to the variable’s location in memory, I think) instead of by their actual value (in your case, the value of an integer.) What I have no idea is why a select node with Pass By Refs does not work with the Increment/Decrement nodes whose input pin is also Pass By Ref!

11

I’ve got the same unowned pin error on my project and it no longer wants to package either.

I have gone through the steps mentioned here and into visual studio. I put the breakpoint at 1045 and I got the following:

EdGraphPinReference	{OwningNode=nullptr PinId={A=2514300252 B=1273906796 C=3355600827 ...} }	const FEdGraphPinReference &

I also have a hexadecimal reference from the output.

Unfortunately, I step in a few times but I did not find anything else for the OwningNode aside from that nullptr reference.

I then just migrated each sublevel to a clean project, and tried to package. I have a sublevel now that does not want to package, but I am unsuccessful at finding the pin that causes the issue. I get different results when I start deleting parts of code from the level blueprint. One time it seemed like the macros were the issue, next it seemed that some regular nodes at the end where the issue. Unfortunately, I have not been able to isolate any node for a second time. It feels really arbitrary.

Does anyone have any suggestions on what else to try? Is there a place where I can find support for this? All my blueprints compile fine.
link text

12

Well, the issue was an unowned pin on the Return Value X of a Get Velocity node. So yes, it was really arbitrary. For anyone in the same position, the trick is to keep copy-pasting blueprints to a text editor and searching for the ID. I used sublime text as it matches automatically and saves time that way.

It posted a bug report here in case anyone wants to have a closer look: