Closed Bug 1468675 Opened 4 years ago Closed 4 years ago

Crash in @0x0 | mozilla::gl::GLContextEGL::IsCurrentImpl


(Core :: Graphics: WebRender, defect)

Windows 10
Not set



Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- unaffected
firefox62 --- fixed


(Reporter: marcia, Assigned: sotaro)


(Blocks 1 open bug)


(Keywords: crash, regression)

Crash Data


(1 file, 2 obsolete files)

This bug was filed from the Socorro interface and is
report bp-04c1bd7a-5093-48c8-bff0-34bc40180614.

Seen while looking at Windows crash stats, looks to have started in Build 20180613220131: Small volume crash so far.

Possible regression range based on Build ID:

Top 10 frames of crashing thread:

0  @0x0 
1 xul.dll mozilla::gl::GLContextEGL::IsCurrentImpl gfx/gl/GLContextProviderEGL.cpp:458
2 xul.dll mozilla::gl::GLContext::MakeCurrent gfx/gl/GLContext.cpp:2965
3 xul.dll mozilla::wr::RenderDXGIYCbCrTextureHostOGL::DeleteTextureHandle gfx/webrender_bindings/RenderD3D11TextureHostOGL.cpp:422
4 xul.dll mozilla::wr::RenderDXGIYCbCrTextureHostOGL::~RenderDXGIYCbCrTextureHostOGL gfx/webrender_bindings/RenderD3D11TextureHostOGL.cpp:273
5 xul.dll mozilla::wr::RenderDXGIYCbCrTextureHostOGL::`scalar deleting destructor' 
6 xul.dll mozilla::PlatformDecoderModule::Release dom/media/platforms/PlatformDecoderModule.h:165
7 xul.dll mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void  xpcom/threads/nsThreadUtils.h:1190
8 xul.dll mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void  
9 xul.dll mozilla::Runnable::Release xpcom/threads/nsThreadUtils.cpp:50

Assignee: nobody → sotaro.ikeda.g
Bug 1364504 seems possible cause of regression.
Blocks: 1364504
The problem seemed to happen only during device reset during video playback. RenderThread::HandleDeviceReset() tries to clear all GLContext related resources. But RenderTextureHosts that is about to be deleted by RenderThread::UnregisterExternalImage() is not handled. We need to address it.

RenderThread::UnregisterExternalImage() posts RenderTextureHost by NewRunnableMethod. It is not good.
Attachment #8985310 - Attachment is obsolete: true
Blocks: wr-stability
Attachment #8985314 - Flags: review?(nical.bugzilla)
Comment on attachment 8985314 [details] [diff] [review]
patch - Fix way of relasing RenderTextureHosts

Review of attachment 8985314 [details] [diff] [review]:

::: gfx/webrender_bindings/RenderThread.h
@@ +200,5 @@
>    nsDataHashtable<nsUint64HashKey, WindowInfo> mWindowInfos;
>    Mutex mRenderTextureMapLock;
>    nsRefPtrHashtable<nsUint64HashKey, RenderTextureHost> mRenderTextures;
> +  std::list<RefPtr<RenderTextureHost>> mRenderTexturesDeferred;

Please add a small comment here explaining why we need this (IIUC: on device resets we want to be able to go through the list of textures that are going to be removed by a deferred callback and remove them right away without waiting for the callback.)

I think it makes sense but in a few months I and others won't remember that (device reset usually not being the first thing we think about when reading the code).
Attachment #8985314 - Flags: review?(nical.bugzilla) → review+
Add comment.
Attachment #8985314 - Attachment is obsolete: true
Attachment #8985415 - Flags: review+
Attachment #8985415 - Attachment description: patch_1468675_3patch - Fix way of relasing RenderTextureHosts → patch - Fix way of relasing RenderTextureHosts
Pushed by
Fix way of relasing RenderTextureHosts r=nical
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Hmm, there is another route to cause the crash.
Resolution: FIXED → ---
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> Hmm, there is another route to cause the crash.
> d3bcc0180616

Ah, current implementation does not support "simulate device reset" handling.
Depends on: 1469480
> Depends on: 1469480

Is this fixed now?
Flags: needinfo?(sotaro.ikeda.g)
Yes. The remaining problem was fixed by bug 1469480.
Closed: 4 years ago4 years ago
Flags: needinfo?(sotaro.ikeda.g)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.