Crash in 4.8 promoted branch: instanced static mesh with no instances

We just integrated the current promoted (4.8 pre-release) branch, and we’re seeing a crash with it that wasn’t happening before.

We add an Instanced Static Mesh (blueprint actor) to the world and then add instances to it. Meanwhile, the ISM starts being rendered via its scene proxy (apparently with no instances), so we hit the following check() at the top of FBatchingSPDI::DrawMesh().

check(Mesh.GetNumPrimitives() > 0);

This only happens if we run standalone - if we run in a “New Editor Window,” everything is fine!

[Note that we did try adding a workaround to early-out of that function if GetNumPrimitives()==0 … it avoids the crash, but the instanced static meshes in question just don’t get rendered, ever.]

Here’s the crash log:

KernelBase.dll!00007ffa4f15e002() Unknown
UE4Editor-Renderer.dll!FBatchingSPDI::DrawMesh(const FMeshBatch & Mesh, float ScreenSize, bool bShadowOnly) Line 45 C++
UE4Editor-Engine.dll!FStaticMeshSceneProxy::DrawStaticElements(FStaticPrimitiveDrawInterface * PDI) Line 536 C++
UE4Editor-Renderer.dll!FPrimitiveSceneInfo::AddStaticMeshes(FRHICommandListImmediate & RHICmdList) Line 143 C++
UE4Editor-Renderer.dll!FPrimitiveSceneInfo::AddToScene(FRHICommandListImmediate & RHICmdList, bool bUpdateStaticDrawLists) Line 187 C++
UE4Editor-Renderer.dll!FScene::AddPrimitiveSceneInfo_RenderThread(FRHICommandListImmediate & RHICmdList, FPrimitiveSceneInfo * PrimitiveSceneInfo) Line 334 C++
UE4Editor-Renderer.dll!FScene::AddPrimitive'::28’::EURCMacro_FAddPrimitiveCommand::DoTask(ENamedThreads::Type CurrentThread, const TRefCountPtr & MyCompletionGraphEvent) Line 539 C++
UE4Editor-Renderer.dll!TGraphTask<FScene::AddPrimitive'::28’::EURCMacro_FAddPrimitiveCommand>::ExecuteTask(TArray & NewTasks, ENamedThreads::Type CurrentThread) Line 669 C++
UE4Editor-Core.dll!FTaskThread::ProcessTasks(int QueueIndex, bool bAllowStall) Line 428 C++
UE4Editor-Core.dll!FTaskThread::ProcessTasksUntilQuit(int QueueIndex) Line 271 C++
UE4Editor-RenderCore.dll!RenderingThreadMain(FEvent * TaskGraphBoundSyncEvent) Line 281 C++
UE4Editor-RenderCore.dll!FRenderingThread::Run() Line 405 C++
UE4Editor-Core.dll!FRunnableThreadWin::Run() Line 73 C++
UE4Editor-Core.dll!FRunnableThreadWin::GuardedRun() Line 48 C++
kernel32.dll!00007ffa4f4d13d2() Unknown
ntdll.dll!00007ffa51c3eb64() Unknown

Threads:

Not Flagged 37320 0 Main Thread Main Thread UE4Editor-Core.dll!FBoxSphereBounds::TransformBy Normal
Not Flagged 36276 0 Worker Thread PoolThread 0 UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 35380 0 Worker Thread PoolThread 1 UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 36020 0 Worker Thread PoolThread 2 UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 37288 0 Worker Thread ScreenSaverInhibitor UE4Editor-Core.dll!FWindowsPlatformProcess::Sleep Normal
Not Flagged 35368 0 Worker Thread mswsock.dll thread mswsock.dll!00007ffa4e54c979 Above Normal
Not Flagged 36936 0 Worker Thread TaskGraphThread 0 UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 35680 0 Worker Thread TaskGraphThread 1 UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 35592 0 Worker Thread TaskGraphThread 2 UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 28288 0 Worker Thread StatsThread UE4Editor-Core.dll!FEventWin::Wait Below Normal
Not Flagged 36048 0 Worker Thread atidxx64.dll thread atidxx64.dll!00007ffa4b0648d3 Normal
Not Flagged 32984 0 Worker Thread ShaderCompilingThread UE4Editor-Core.dll!FWindowsPlatformProcess::Sleep Normal
Not Flagged 35952 0 Worker Thread AsyncIOSystem UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 34088 0 Worker Thread ntdll.dll thread ntdll.dll!00007ffa51c628ca Normal
Not Flagged 37420 0 Worker Thread FMessageBus.Router UE4Editor-Core.dll!FEventWin::Wait Normal
Not Flagged 37588 0 Worker Thread FDDCCleanup UE4Editor-Core.dll!FWindowsPlatformProcess::Sleep Below Normal
Not Flagged 34112 0 Worker Thread msvcrt.dll thread RTWorkQ.dll!00007ffa4a576bfd Time Critical
Not Flagged 35824 0 Worker Thread ntdll.dll thread ntdll.dll!00007ffa51c628ca Normal
Not Flagged 23208 0 Worker Thread combase.dll thread combase.dll!00007ffa4fd88e0e Normal
Not Flagged 17320 0 Worker Thread ntdll.dll thread ntdll.dll!00007ffa51c628ca Normal
Not Flagged 36796 0 Worker Thread ntdll.dll thread ntdll.dll!00007ffa51c628ca Normal
Not Flagged 37148 0 Worker Thread FAndroidDeviceDetectionRunnable UE4Editor-Core.dll!FWindowsPlatformProcess::Sleep Normal
Not Flagged > 27264 0 Worker Thread RenderThread 1 UE4Editor-Renderer.dll!FBatchingSPDI::DrawMesh Normal
Not Flagged 37076 0 Worker Thread RTHeartBeat 1 UE4Editor-Core.dll!FWindowsPlatformProcess::Sleep Above Normal
Not Flagged 34116 0 Worker Thread FFileTransferRunnable UE4Editor-Core.dll!FEventWin::Wait Below Normal
Not Flagged 34124 0 Worker Thread TAsync 0 UE4Editor-Core.dll!FRunnableThreadWin::~FRunnableThreadWin Normal
Not Flagged 34084 0 Worker Thread TAsync 1 UE4Editor-Core.dll!FRunnableThreadWin::~FRunnableThreadWin Normal
Not Flagged 35396 0 Worker Thread TAsync 2 UE4Editor-Core.dll!FRunnableThreadWin::~FRunnableThreadWin Normal
Not Flagged 22312 0 Worker Thread TAsync 3 UE4Editor-Core.dll!FRunnableThreadWin::~FRunnableThreadWin Normal
Not Flagged 37664 0 Worker Thread XAudio2_7.dll thread XAudio2_7.dll!00007ffa0ce32891 14
Not Flagged 34764 0 Worker Thread ntdll.dll thread ntdll.dll!00007ffa51c628ca Normal
Not Flagged 34632 0 Worker Thread ntdll.dll thread ntdll.dll!00007ffa51c628ca Normal
Not Flagged 27352 0 Worker Thread atidxx64.dll thread atidxx64.dll!00007ffa4ab99fd0 Normal
Not Flagged 34140 0 Worker Thread atidxx64.dll thread atidxx64.dll!00007ffa4ab99fd0 Normal

I’ve also attached the above as a separate text file in case you find that more readable.

link text

By the way, this crash is preventing us from sending an updated build to our publisher, so we appreciate any hotfixes you could provide.

Also, we’d be happy to provide our source code if it would help you repro the issue. Just let me know.

Hey guys,

We shouldn’t need any source code unless you’ve made changes to the ISM system.

However, a small project with a test case that exhibits the problem would be very helpful.

Hi Mark – we spent a few hours trying to put a test together but we’ve been unsuccessful.

At this point, we’d really like to just give you our project so you can repro it yourselves, since this is holding us up and keeping us from sending a build to our publishers.

What’s the best way to get it to you? Unfortunately, it’s several gigabytes; do you have an FTP or something like that?

The blueprintoffice example seems able to repro this issue. We are working on a fix.

I believe this was fixed yesterday.

https://github.com/EpicGames/UnrealEngine/commit/1afa856ab46cdd51aef07a883025c56d3042d184

This is fixed in the main branch as of changelist 2472770, should be straightforward for you to integrate it.

Thank you for the change; unfortunately, this doesn’t quite fix it.

The good news it that it does avoid a crash.

The bad news is that the instanced static meshes still do not appear – we get the same results as our original attempted workaround of returning from that function when Mesh.GetNumPrimitives() == 0 … those instanced static meshes just don’t show up at all.

What’s the next step? Can we get you our source code, or is there something we can do on our end to help you investigate this further?

Ok, so few things: Is this PC or mobile? If it’s PC, you can try using RenderDoc which is what I use to make sure the draw calls are there (use toggledrawevents and showmaterialdrawevents on the console), the material was setup right, etc. If it’s iOS, you can use Xcode’s frame capture and do the same. If you’re on Android, I unfortunately have no tips :frowning:
On PC you can also try running with -opengl to see if it’s an engine issue or an rhi issue.
How are you setting the instanced meshes, via blueprints or c++ code, etc?
You can also debug it from FInstancedStaticMeshSceneProxy::GetDynamicMeshElements(), try to find if it’s returning the right numbers you expect.

Thanks, RCaloca – we’re looking into it right now. We’ll try to get you more info.

This is PC only.

Again, this is still working fine in a New Editor Window, but not in Standalone games, which is quite odd.

The quick fix is to replace this:

InstanceData->SetAllowCPUAccess(InstanceData->GetAllowCPUAccess() || bNeedsCPUAccess);

With this:

	InstanceData->SetAllowCPUAccess(true);

I will check in the more elaborate fix shortly. That will discard the wasted memory but still function correctly.

That did it – thank you, Gil!!!