This is essentially a copy of the issue described in [Content removed] which was closed without resolution. We are also seeing this on creation of a UNiagaraScript object. Our repro steps are as following and is 100% for at least one specific Niagara System asset, but certainly not all:
- Open problematic Niagara System asset.
- Disable any one of the three emitters with the check box at the top.
- Observe failed assertion
I have followed some of the debugging hints provided in the previous thread, but no progress yet.
I should also mention that when opening the asset I get this. Not sure if this is related or not:
Ensure condition failed: bAlreadyHandled == false [File:C:\p4\game\Engine\Plugins\FX\Niagara\Source\NiagaraEditor\Private\ViewModels\Stack\NiagaraStackEntry.cpp] [Line: 803]
Duplicate child Scale Curve (NiagaraStackFunctionInput) in entry Filtered Inputs (NiagaraStackSummaryViewCollection).
[Attachment Removed]
Here is the call stack, which did not make in in my original question:
GameEditor_Core!FDebug::CheckVerifyFailedImpl2()
GameEditor_CoreUObject!UObjectBaseUtility::MarkAsGarbage()
GameEditor_CoreUObject!StaticConstructObject_Internal()
GameEditor_NiagaraEditor!UNiagaraNodeAssignment::GenerateScript()
GameEditor_NiagaraEditor!UNiagaraNodeAssignment::RefreshFromExternalChanges()
GameEditor_NiagaraEditor!UNiagaraScriptSource::RefreshFromExternalChanges()
GameEditor_Niagara!FNiagaraEmitterHandle::SetIsEnabled()
GameEditor_NiagaraEditor!FNiagaraEmitterHandleViewModel::SetIsEnabled()
GameEditor_NiagaraEditorWidgets!SNiagaraOverviewStackNode::OnEnabledCheckStateChanged()
GameEditor_NiagaraEditorWidgets!TBaseSPMethodDelegateInstance<0,SNiagaraOverviewStackNode,1,void cdecl(enum ECheckBoxState),FDefaultDelegateUserPolicy>::ExecuteIfSafe()
GameEditor_Slate!SCheckBox::ToggleCheckedState()
GameEditor_Slate!SCheckBox::OnMouseButtonUp()
GameEditor_Slate!FEventRouter::Route<FReply,FEventRouter::FToLeafmostPolicy,FPointerEvent,FSlateApplication::RoutePointerUpEvent'::8'::<lambda_2> >()
GameEditor_Slate!FSlateApplication::RoutePointerUpEvent()
GameEditor_Slate!FSlateApplication::ProcessMouseButtonUpEvent()
GameEditor_Slate!FSlateApplication::OnMouseUp()
GameEditor_ApplicationCore!FWindowsApplication::ProcessDeferredMessage()
GameEditor_ApplicationCore!FWindowsApplication::DeferMessage()
GameEditor_ApplicationCore!FWindowsApplication::ProcessMessage()
GameEditor_ApplicationCore!FWindowsApplication::AppWndProc()
user32
user32
GameEditor_ApplicationCore!FWindowsPlatformApplicationMisc::PumpMessages()
GameEditor!FEngineLoop::Tick()
GameEditor!GuardedMain()
GameEditor!GuardedMainWrapper()
GameEditor!LaunchWindowsStartup()
GameEditor!WinMain()
GameEditor!scrt_common_main_seh()
kernel32
ntdll
[Attachment Removed]
Hi Fredrik,
I’ve reached out to the dev team, and they would be very grateful for a repro. Are you able to provide this - maybe using the suspect asset is a new level or similar?
Best
Geoff Stacey
Developer Relations
EPIC Games
[Attachment Removed]
Hi Fredrik,
Looking at the callstack above it’s hitting an assert, can you post the assert message? If in the editor it should be in the log, or if in the debugger check the output window. The assert message from the NiagaraStackEntry is an indication of a different problem, but the surrounding code handles it without issue, so it’s unrelated. The callstack above is more concerning because it’s happening in the core uobject code, but it’s not clear what the actual issue is.
Thanks,
Frank
[Attachment Removed]
There is no assert message, just a “check(!IsRooted());” that fails in UObjectBaseUtility::MarkAsGarbage()
[Attachment Removed]
Hi, thanks for looking into this!
I’ll work on isolating a repro today
[Attachment Removed]
No luck with isolating a repro. However, I did manage to track down why the object in question was added to the root set in the first place. Turns out we have a custom class deriving from UDeveloperSettings that hard references a blueprint. This blueprint in turn references the Niagara system among other things. Early when booting the editor the default constructed developer settings will get added to the root set along with everything it references. I have attempted to fix this on our end by instead soft referencing the BP class and loading it on spawn instead. This seems to have resolved the crash at least 
.
In our case the early load of those assets might not have been intentional, so this was probably good to take care of. But whether intentional or not it probably shouldn’t crash the editor, so might be worth looking into. I mean the original setup we had is still valid, right? As far as I know, the only issue is we’ve had with it is the crash in the Niagara editor. The fact that I can’t reproduce this with the setup described above might mean that it has already been fixed in one of the patch versions (which we do not have afaik).
[Attachment Removed]
You are correct, it definitely should not crash the editor. I’ve added an issue to try to figure out a reproduction case for this so that I can be fixed in a future release. Thanks for your help on this.
[Attachment Removed]