1841894 - Crash in [@ NtSetEvent]

Status: RESOLVED INACTIVE

(Core :: Graphics: WebRender, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

All on 32-bit Windows.

Crash report: https://crash-stats.mozilla.org/report/index/29b7caad-5b8a-4d78-80c4-6a3830230705

Reason: EXCEPTION_INVALID_HANDLE

Top 10 frames of crashing thread:

0  ntdll.dll  NtSetEvent  
1  KERNELBASE.dll  SetEvent  
2  igd10iumd32.dll  igd10iumd32.dll@0x9e8761  
3  d3d11.dll  void __thiscall CGeometryShader::CLS::FinalConstruct  
4  d3d11.dll  static void __stdcall TCLSWrappers<class CGeometryShader>::CLSFinalConstructFn  
5  d3d11.dll  void __thiscall CLayeredObjectWithCLS<class CGeometryShader>::FinalConstruct  
6  d3d11.dll  static void __stdcall CLayeredObjectWithCLS<class CGeometryShader>::CreateInstance  
7  d3d11.dll  CDevice::CreateLayeredChild  
8  d3d11.dll  virtual long __stdcall CBridgeImpl<struct ID3D11LayeredDevice, struct ID3D11LayeredDevice, class CLayeredObject<class CDevice> >::CreateLayeredChild  
9  d3d11.dll  long __thiscall NDXGI::CDevice::CreateLayeredChild  

Comment 1

[Lee Salzman [:lsalzman]]

Glenn, Kelsey, not entirely sure what's going on here? It looks like this particular thread may be an ANGLE or driver thread? But the Renderer thread looks like it is inside a call to detach_shader that happens immediately after a link_program, here: https://hg.mozilla.org/mozilla-central/file/243ab04b37e31315f3db16a95bf6535124d9edda/gfx/wr/webrender/src/device/gl.rs#l2494

It looks like vaguely those may be related, as other reports have the same pattern of being inside detach_shader in the Renderer thread when this crash happens.

Comment 2

[Glenn Watson [:gw]]

Not clear to me what's happening either. I vaguely recall that we might do some of the shader pre-compilation / program loading on a background thread? Or maybe we rely on an ANGLE extension to do them in the background? I think that Sotaro may have implemented this, he might have an idea.

Comment 3

[Sotaro Ikeda [:sotaro]]

I checked some crash reports. The all reports had CDevice::CreateLayeredChild call. Then it seemed that driver's resource allocation might fail.

Comment 4

[Glenn Watson [:gw]]

Given the volume and lack of repro steps, there is nothing we can do about this. Closing for now, but please reopen if volume or relevant information changes.