Description

We've been seeing asserts and crashes related to OwnerLastRenderTimePtr. We've traced this to the mentioned pointer ending up dangling after using UActorComponent::Rename() on primitive components to reuse/reparent them, for example:

  1. WeaponMeshComponent->Rename(nullptr, WeaponActor);

Where:

  • WeaponMeshComponent is derived from PrimitiveComponent
  • WeaponActor is a newly created actor
  • The previous owner of WeaponMeshComponent is being destroyed

The problem is that WeaponMeshComponent's SceneData.OwnerLastRenderTimePtr pointer still points to the old parent object being destroyed. The code in UPrimitiveComponent::ReleaseSceneProxy() that accesses this pointer can crash directly or corrupt mem elsewhere via the atomic operation on SceneData.OwnerLastRenderTimePtr->NumAlwaysVisibleComponents. We trapped this with stomp malloc.

Potential fix that has eliminated lots of the random crashes in our testing so far is to add this PostRename method.

  1. void UPrimitiveComponent::PostRename(UObject* OldOuter, const FName OldName)
  2. {
  3. Super::PostRename(OldOuter, OldName);
  4.  
  5. FActorLastRenderTime* OldLastRenderTimePtr = SceneData.OwnerLastRenderTimePtr;
  6. FActorLastRenderTime* NewLastRenderTimePtr = FActorLastRenderTime::GetPtr(GetOwner());
  7.  
  8. if (OldLastRenderTimePtr &&
  9. OldLastRenderTimePtr != NewLastRenderTimePtr)
  10. {
  11. SceneData.OwnerLastRenderTimePtr = NewLastRenderTimePtr;
  12.  
  13. // Update the Number of visible components on the new owner if we are always visible,
  14. // otherwise we'll assert later due to this count being off when releasing the sceneproxy
  15. if (SceneData.bAlwaysVisible && SceneData.OwnerLastRenderTimePtr)
  16. { # SceneData.OwnerLastRenderTimePtr->NumAlwaysVisibleComponents.fetch_add(1, std::memory_order_relaxed); # }
  17. }
  18. }
Steps to Reproduce

Steps to Reproduce

No repro, very rare crash.

 

Callstack

EXCEPTION_ACCESS_VIOLATION_READ / 0x1e3afd05da4: Fatal Error: EXCEPTION_ACCESS_VIOLATION_READ / 0x1e3afd05da4

TBitArray::SetRange (BitArray.h:897)

TSparseSpanArray::RemoveSpan (LumenSparseSpanArray.h:65)

FLumenSceneData::RemovePrimitiveGroupCullingInfo (LumenMeshCards.cpp:626)

UpdateLumenScenePrimitives (LumenScene.cpp:857)

`FDeferredShadingSceneRenderer::BeginUpdateLumenSceneTasks'::`2'::::operator() (LumenSceneRendering.cpp:2043)

FRDGBuilder::AddSetupTask::__l2::::operator() (RenderGraphBuilder.inl:603)

Invoke (Invoke.h:47)

UE::Tasks::Private::TExecutableTaskBase::ExecuteTask (TaskPrivate.h:905)

UE::Tasks::Private::FTaskBase::TryExecuteTask (TaskPrivate.h:527)

UE::Tasks::Private::FTaskBase::Init::__l2::::operator() (TaskPrivate.h:184)

LowLevelTasks::FTask::Init::__l5::::operator() (Task.h:499)

Invoke (Invoke.h:47)

LowLevelTasks::TTaskDelegate::TTaskDelegateImpl::Call (TaskDelegate.h:162)

LowLevelTasks::TTaskDelegate::TTaskDelegateImpl::CallAndMove (TaskDelegate.h:171)

LowLevelTasks::TTaskDelegate::CallAndMove (TaskDelegate.h:309)

LowLevelTasks::FTask::ExecuteTask (Task.h:627)

LowLevelTasks::FScheduler::ExecuteTask (Scheduler.cpp:397)

LowLevelTasks::FScheduler::TryExecuteTaskFrom (Scheduler.cpp:665)

LowLevelTasks::FScheduler::WorkerLoop (Scheduler.cpp:724)

LowLevelTasks::FScheduler::WorkerMain (Scheduler.cpp:783)

`LowLevelTasks::FScheduler::CreateWorker'::`2'::::operator() (Scheduler.cpp:188)

UE::Core::Private::Function::TFunctionRefBase::operator() (Function.h:471)

FThreadImpl::Run (Thread.cpp:66)

FRunnableThreadWin::Run (WindowsRunnableThread.cpp:156)

FRunnableThreadWin::GuardedRun (WindowsRunnableThread.cpp:79)

KERNEL32.DLL 0x7ff8173ee8d6 BaseThreadInitThunk

ntdll 0x7ff81856c40b RtlUserThreadStart

Have Comments or More Details?

There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-370040 in the post.

0
Login to Vote

Fixed
ComponentUE - World Creation - Worldbuilding Tools
Affects Versions5.6
Target Fix5.8
Fix Commit52158667
CreatedMar 16, 2026
ResolvedMar 26, 2026
UpdatedMay 28, 2026
View Jira Issue