Crash in Material Graph When Connecting To MaterialExpressionCustom Node Input

Development Asset Creation
, ,
1

Hello! We have a dev crashing while making a connection to an input of a UMaterialExpressionCustom node. We unfortunately have not come up with a solid repro, and only the one dev has encountered this issue.

Despite not having a solid repro, it happens enough to be pretty detrimental. The user is doing a lot of scripting in the UMaterialExpressionCustom node, and I noticed that they tend to insert new inputs to the node in the middle of input list.

Source line below, the OwnerNodePtr is invalid:

TSharedPtr<SGraphPanel> Panel = OwnerNodePtr.Pin()->GetOwnerPanel();

The widget owner of the Pin has been deleted.

Below is the assertion:

Assertion failed: IsValid() [File:…\Engine\Source\Runtime\Core\Public\Templates\SharedPointer.h] [Line: 1113]

I’ve also attached a partial screenshot of what the editor looks like at the moment of the crash.

I’m wondering if this is a known issue (or even better - a known issue with a fix)! Thanks for taking a look at this.

2

Steps to Reproduce
In a complex material graph with a UMaterialExpressionCustom node with 4+ inputs:

  1. Insert a new input in the middle of the input list to the MaterialExpressionCustom node.
  2. Add a new graph node like a scalar parameter and connect it to that new input
  3. Add another new input to the MaterialExpressionCustom node below the new input in step 1.
  4. Create another new graph node and connect it to that additional input from step 3.
  5. Crash
3

Hello,

Thank you for reaching out.

I’ve been assigned this issue, and we will be looking into it for you.

We have been unable to reproduce this crash after several attempts.

Is there any other information you can provide that might help us reproduce it?

4

Hey, I checked again with the dev experiencing this issue and unfortunately they have been unable to provide me with more information than what I’ve already posted.

However, I can provide some more information based on debugging a crash dump, and I would like feedback on a fix I am thinking about making.

When I debug the dump in SGraphPin::OnMouseLeave, I can see that although the OwnerNodePtr is being shown as ‘Object has been destroyed’, but the raw pointer is showing that the object’s memory is still intact.

I see that the OwnerNode SGraphNode still has it’s InputPins and OutputPins arrays populated with sharedpointers. Also, the crashing pin’s bGraphDataInvalid is true. It appears like the InputPins and OuptutPins arrays are keeping these invalid pins from being destroyed (shared pointers are showing only 1 remaining reference).

I propose adding the following code to the end of SGraphNode::InvalidateGraphData():

I notice that this same logic is used in other places when SGraphNode::InvalidateGraphData() is called, such as in SRigVMGraphNode::HandleNodeBeginRemoval and SRigVMGraphNodeKnot::HandleNodeBeginRemoval.

I think it makes sense to release these pin shared pointers when a graph is invalidated. I am having the dev encountering this crash test this change. My local tests appear to work fine.

Again, I would appreciate feedback on this fix. Thank you!

5

For some reason, the code snippet fix I proposed adding to the end of SGraphNode::InvalidateGraphData() is not displaying publicly. I’ll add that code in plain text here:

//Fix START

for (const TSharedRef<SGraphPin>& GraphPin : InputPins)

{

GraphPin->SetPinObj(nullptr);

}

for (const TSharedRef<SGraphPin>& GraphPin : OutputPins)

{

GraphPin->SetPinObj(nullptr);

}

InputPins.Reset();

OutputPins.Reset();

//FIX END

6

Hello,

Editing SGraphNode as you suggest might have unintended consequences - it is the base class for all nodes in Unreal Engine.

UMaterialExpressionCustom manually reconstructs it’s SGraphNode, see “UMaterialExpressionCustom::PostEditChangeProperty(…)” from MaterialExpressions.cpp.

If you can make a test project that shows this crash, we can try investigating this code path to find what is happening.

The guide for test projects: [Content removed]

7

Hello again!

Thanks for the response. As an update, the dev encountering this crash has tested my change and it definitely fixes the issue (they were crashing several times a week previously).

Unfortunately, due to the rarity of the crash, (we have only encountered this on one machine with no regular repro) we will not be able to provide a test project. That said, everything in the crash dump lines up with SGraphPanel::PurgeVisualRepresentation() having been called, and some SGraphPins still remaining with an invalid owner.

I hear ya on the risk of changing SGraphNode. I will modify the change to make SGraphNode::InvalidateGraphData() a virtual function and override it in SGraphNodeMaterialBase to add my above fix. That way, the change only applies to material nodes. Note: Our engine does have some modifications, so although it is possible that this doesn’t happen in vanilla UE5, I have not found any modifications to the material editor that are suspect.

I will plan on checking this into our codebase at the end of the week if all continues to go well.

8

I’ll try to provide some more info based on your questions, but unfortunately there is not much more I can offer. I attempted to be as explicit as I can from reports from the dev encountering the issue. We do have one video, but due to the sensitivity of our project, I won’t be sharing it. Studio QA and myself have followed the video many times and have still been unable to repro.

I have not found anything of note on the machine that might affect this issue. Shader debugging is enabled was the only config difference I could find. The graph state before the repro happens always seems to be an error on the materialexpressionnode as shown in the screenshot. Also as I noted, the dev likes to add inputs in the middle of the custom node input list, which seemed unusual to me. This is a build made on-device (local compilation). Although it is worth mentioning, we actually got this dev a new pc while working on this issue, and the problem went away for a little while before returning - so that makes me think it is not hardware related.

Since the dev is no longer encountering the issue after my fix - and it affected only a single person - we are cycling off the problem. My main goal of this thread was to see if this was a known issue and/or fixed already. I greatly appreciate the support + follow up, and regret that I can’t get you all better info or a solid repro.

That said, I consider this issue resolved. I will reply to this thread or reference it if any new information on this issue comes to light.

9

One other detail. This ensure happens sometimes shortly before the crash, but not always.

[2025.04.24-18.13.23:263][685]LogOutputDevice: Error: === Handled ensure: ===

[2025.04.24-18.13.23:264][685]LogOutputDevice: Error:

[2025.04.24-18.13.23:264][685]LogOutputDevice: Error: Ensure condition failed: !bGraphDataInvalid [File:…\Engine\Source\Editor\GraphEditor\Private\SGraphPin.cpp] [Line: 1355]

[2025.04.24-18.13.23:264][685]LogOutputDevice: Error:

[2025.04.24-18.13.23:264][685]LogOutputDevice: Error: Stack:

[2025.04.24-18.13.23:264][685]LogOutputDevice: Error: [Callstack] 0x00007ff982d840fd UnrealEditor-GraphEditor.dll!SGraphPin::GetTooltipText() […\Engine\Source\Editor\GraphEditor\Private\SGraphPin.cpp:1355]

[2025.04.24-18.13.23:264][685]LogOutputDevice: Error: [Callstack] 0x00007ff982d7d8ca UnrealEditor-GraphEditor.dll!TBaseSPMethodDelegateInstance<1,SGraphPin const ,1,FText __cdecl(void),FDefaultDelegateUserPolicy>::Execute() […\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl.h:282]

[2025.04.24-18.13.23:264][685]LogOutputDevice: Error: [Callstack] 0x00007ff999faf220 UnrealEditor-Slate.dll!TAttribute<FText>::Get() […\Engine\Source\Runtime\Core\Public\Misc\Attribute.h:251]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff99a335624 UnrealEditor-Slate.dll!SToolTip::IsEmpty() […\Engine\Source\Runtime\Slate\Private\Widgets\SToolTip.cpp:92]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff99a0c9c58 UnrealEditor-Slate.dll!FSlateUser::UpdateTooltip() […\Engine\Source\Runtime\Slate\Private\Framework\Application\SlateUser.cpp:1264]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff999fe89f6 UnrealEditor-Slate.dll!FSlateApplication::TickPlatform() […\Engine\Source\Runtime\Slate\Private\Framework\Application\SlateApplication.cpp:1613]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff999fe7682 UnrealEditor-Slate.dll!FSlateApplication::Tick() […\Engine\Source\Runtime\Slate\Private\Framework\Application\SlateApplication.cpp:1543]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff7b8978e2e UnrealEditor.exe!FEngineLoop::Tick() […\Engine\Source\Runtime\Launch\Private\LaunchEngineLoop.cpp:5999]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff7b899c96d UnrealEditor.exe!GuardedMain() […\Engine\Source\Runtime\Launch\Private\Launch.cpp:225]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff7b899caea UnrealEditor.exe!GuardedMainWrapper() […\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:118]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff7b899ff80 UnrealEditor.exe!LaunchWindowsStartup() […\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:330]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff7b89b5314 UnrealEditor.exe!WinMain() […\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:370]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ff7b89b89da UnrealEditor.exe!__scrt_common_main_seh() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ffab5247374 KERNEL32.DLL!UnknownFunction

[2025.04.24-18.13.23:265][685]LogOutputDevice: Error: [Callstack] 0x00007ffab54bcc91 ntdll.dll!UnknownFunction

10

Hello,

Is there any other information you can offer us to help reproduce the issue? For example, is there anything special about this machine that might be affecting it? Are there any order of events, mouse position, and/or graph state that seems to make it more likely? Is this machine using a distributed build, or a build made on-device?

If it is possible, can you try and share a video of the crash reproduction? If the reproduction is too rare or irregular, we understand. We might be able to get more information about the reproduction requirements from that.

11

Hello,

Thank you for sharing this extra information.

I will close this ticket for now. Please feel free to re-open it if you have additional questions.