Editor Crashes (OS X) when viewing SpeedTree Material

In OS X with UE version 4.12.5, when I attempt to view any SpeedTree material, the editor crashes. Crash dump here:

2016.07.28-14.59.20:377][487]MaterialEditorStats: Info Texture samplers: 2/16

[2016.07.28-14.59.20:436][488]LogMac: === Critical error: ===
SIGSEGV: invalid attempt to access memory at address 0x30

[2016.07.28-14.59.20:436][488]LogMac: ShaderBindingStage::updateConstantTable(unsigned int, unsigned int) Address = 0x2de62f60 (filename not found) [in AppleIntelBDWGraphicsMTLDriver]^M
ShaderBindingStage::updateBindingTableData() Address = 0x2de638a0 (filename not found) [in AppleIntelBDWGraphicsMTLDriver]^M
ShaderBindingStage::writeIf() Address = 0x2de63c07 (filename not found) [in AppleIntelBDWGraphicsMTLDriver]^M
IGAccelRenderCommandEncoder::programPipeline(sPrimitiveData const&) Address = 0x2de57c96 (filename not found) [in AppleIntelBDWGraphicsMTLDriver]^M
IGAccelRenderCommandEncoder::drawIndexedPrimitives(MTLPrimitiveType, unsigned int, MTLIndexType, MTLIGAccelBuffer*, unsigned int, unsigned int, unsigned int, unsigned int) Address = 0x2de587c4 (filename not found) [in AppleIntelBDWGraphicsMTLDriver]^M
-[MTLIGAccelRenderCommandEncoder drawIndexedPrimitives:indexCount:indexType:indexBuffer:indexBufferOffset:instanceCount:baseVertex:baseInstance:] Address = 0x2de46ddc (filename not found) [in AppleIntelBDWGraphicsMTLDriver]^M
FMetalRHICommandContext::RHIDrawIndexedPrimitive(FRHIIndexBuffer*, unsigned int, int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) Address = 0x2fcd489e (filename not found) [in UE4Editor-MetalRHI.dylib]^M
FMeshDrawingPolicy::DrawMesh(FRHICommandList&, FMeshBatch const&, int, bool) const Address = 0xf79685a (filename not found) [in UE4Editor-Renderer.dylib]^M
void FDrawBasePassDynamicMeshAction::Process(FRHICommandList&, FProcessBasePassMeshParameters const&, FUniformLightMapPolicy const&, FUniformLightMapPolicy::ElementDataType const&) const Address = 0xf66ba19 (filename not found) [in UE4Editor-Renderer.dylib]^M
void ProcessBasePassMesh(FRHICommandList&, FProcessBasePassMeshParameters const&, FDrawBasePassDynamicMeshAction const&) Address = 0xf60b0ef (filename not found) [in UE4Editor-Renderer.dylib]^M
FBasePassOpaqueDrawingPolicyFactory::DrawDynamicMesh(FRHICommandList&, FViewInfo const&, FBasePassOpaqueDrawingPolicyFactory::ContextType, FMeshBatch const&, bool, bool, FPrimitiveSceneProxy const*, FHitProxyId, bool) Address = 0xf5b825f (filename not found) [in UE4Editor-Renderer.dylib]^M
FDeferredShadingSceneRenderer::RenderBasePassDynamicData(FRHICommandList&, FViewInfo const&, bool&) Address = 0xf5dd874 (filename not found) [in UE4Editor-Renderer.dylib]^M
FDeferredShadingSceneRenderer::RenderBasePass(FRHICommandListImmediate&) Address = 0xf5f3cef (filename not found) [in UE4Editor-Renderer.dylib]^M
FDeferredShadingSceneRenderer::Render(FRHICommandListImmediate&) Address = 0xf5e6b30 (filename not found) [in UE4Editor-Renderer.dylib]^M
FRendererModule::BeginRenderingViewFamily(FCanvas*, FSceneViewFamily*)::EURCMacro_FDrawSceneCommand::DoTask(ENamedThreads::Type, TRefCountPtr const&) Address = 0xfbcf7f3 (filename not found) [in UE4Editor-Renderer.dylib]^M
TGraphTask::ExecuteTask(TArray&, ENamedThreads::Type) Address = 0xfc0200b (filename not found) [in UE4Editor-Renderer.dylib]^M
FNamedTaskThread::ProcessTasksNamedThread(int, bool) Address = 0x6c7810 (filename not found) [in UE4Editor-Core.dylib]^M
FNamedTaskThread::ProcessTasksUntilQuit(int) Address = 0x6c3215 (filename not found) [in UE4Editor-Core.dylib]^M
FTaskGraphImplementation::ProcessThreadUntilRequestReturn(ENamedThreads::Type) Address = 0x6bf7d1 (filename not found) [in UE4Editor-Core.dylib]^M
RenderingThreadMain(FEvent*) Address = 0x71dbfd4 (filename not found) [in UE4Editor-RenderCore.dylib]^M
FRenderingThread::Run() Address = 0x71f2b17 (filename not found) [in UE4Editor-RenderCore.dylib]^M
FRunnableThreadPThread::Run() Address = 0x717328 (filename not found) [in UE4Editor-Core.dylib]^M
FRunnableThreadPThread::_ThreadProc(void*) Address = 0x6d9371 (filename not found) [in UE4Editor-Core.dylib]^M
_pthread_body() Address = 0x92a2999d (filename not found) [in libsystem_pthread.dylib]^M
_pthread_body() Address = 0x92a2991a (filename not found) [in libsystem_pthread.dylib]^M
thread_start() Address = 0x92a27351 (filename not found) [in libsystem_pthread.dylib]^M

Hey schubboy,

So we do have a bug already reported dealing with a crash when SpeedTree and shaders are compiling after initial import. This issue can be found on our Public Issues Tracker.

In order to test this issue I had to use the workaround provided in the bug report, but that being said I was unable to reproduce your crash in a new blank project using one of the free SpeedTree Samples.

Generally when reporting crashes like the one you are experiencing, we will request a more verbose report in order to gather all the necessary information in order to track and log the bug. Take a look at our How to Report a Bug sticky on the forums to get an idea of all the information we will need in order to generate a bug report.

With that said, do you have steps for me to follow so I can reproduce this with minimal content in a new blank project?

Let me know if you have further questions or need additional assistance.


Steps to reproduce are within OSX:

Setup: Brand new C++ project, all default options, no starter content.

1.) Import any SpeedTree model via Unreal Editor → Content Pane → right-click → Import
2.) Utilize workaround to known Speed Tree bug → Do NOT check “Smooth LOD”. Leave “Wind” checked
3.) Double-click any speedtree material to open the material editor
4) Wait approximately 15 - 30 seconds for the system to finish shader compilation
5) The material previewer will never show the material and the system will crash before the sphere/plane/preview mesh ever changes from WorldGridMaterial to the speedtree material preview.

I should mention: iMac Late 2015 with Iris Pro Graphics, 16GB RAM, 3.3Ghz i7, OSX latest patches - 10.11.6, Unreal Editor, latest version 4.12.5, C++ project, blank, no starter content. Substance Designer plugin enabled.

Broadleaf_Mobile.srt from the Free UE4 Samples pack was used for this test as well, but I’ve had our purchased UE4 samples fail as well, from the desktop ground cover pack.

Great! Thank you for the clear and concise repro steps. I was able to reproduce the crash on my end using the steps you provided. The interesting thing is that this issue shares a similar callstack, and the crash reporter points directly to a known and reported issue that seems unrelated.

I have commented internally on this report for clarification on the direction needed for this issue. Once I have more information I will return here and updated you with my findings.

Update: After further investigation we have determined your issue is the same as UE-32068. The good news is the issue has already been fixed for 4.13.

Let me know if you have further questions or need additional assistance.


Thanks Andrew, you guys are doing a great job! I appreciate the response.