1354622 - Crash in TlsFreeStub

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-510bcb98-5c52-4d0f-afec-e2b7b2170407.
=============================================================

Seen while looking at crash stats - crashes on 55 go as far back as 20170314030215: http://bit.ly/2oaGbcL

Crashes on Firefox 54 as well.

Comment 1

[Peter Chang[:pchang]]

From the past month, we had 136 reports.
Michael, could you check this were related to recently ANGLE update?


1 	55.0a1 	92 	67.65 %
2 	54.0a2 	30 	22.06 %
3 	54.0b3 	7 	5.15 %
4 	54.0b2 	4 	2.94 %
5 	54.0b1 	3 	2.21 %

Comment 2

[Michael Leu[:Lenzak](UTC+8)]

ANGLE 2950 landed on 4/11/2017, which merged into 55, so this crash has been around before it landed.

From the crash stack, it seems that we attempt to delete a windows thread with corrupted internal state.

We are uncertain about the cause of the crash for now.

I suspect it is related to shader compiling, maybe it is caused by an improper delete in a middle of shader compiling.

I think we should add diagnostic logs in shader compilation code for further identification.

Comment 3

[Michael Leu[:Lenzak](UTC+8)]

So far we can only know this crash happens when we are deleting a WebGL1Context with ANGLE backend, however, I cannot find any code trace in the stack called TlsFree which caused the crash, so I think maybe the actually crash point is not in the stack but invoked along with context deletion as well.

https://dxr.mozilla.org/mozilla-central/rev/b21b974d60d3075ae24f6fb1bae75d0f122f28fc/gfx/angle/src/libGLESv2/global_state.cpp#143
https://dxr.mozilla.org/mozilla-central/rev/b21b974d60d3075ae24f6fb1bae75d0f122f28fc/gfx/angle/src/compiler/translator/InitializeDll.cpp#39

I suspect the actual crash point is one of the links above since they are few codes actually call TlsFree.

Both of the lines are called when we are deleting a context.

Comment 4

[Michael Leu[:Lenzak](UTC+8)]

This is the closest stack I can reproduce comparing to the crash, but strange enough, all the crashes called TlsFreeStub instead of actual __imp__TlsFree here, it seems that their kernel32.dll got hooked by something.

        kernel32.dll!__imp__TlsFree@4
>	libGLESv2.dll!DestroyTLSIndex(unsigned long index) Line 92	C++
 	libGLESv2.dll!sh::FreeParseContextIndex() Line 31	C++
 	libGLESv2.dll!sh::DetachProcess() Line 39	C++
 	libGLESv2.dll!ShFinalize() Line 127	C++
 	libGLESv2.dll!gl::Compiler::release() Line 155	C++
 	libGLESv2.dll!gl::Compiler::~Compiler() Line 117	C++
 	libGLESv2.dll!SafeDelete<gl::Compiler>(gl::Compiler * & resource) Line 67	C++
 	libGLESv2.dll!gl::Context::~Context() Line 444	C++
 	libGLESv2.dll!SafeDelete<gl::Context>(gl::Context * & resource) Line 67	C++
 	libGLESv2.dll!egl::Display::destroyContext(gl::Context * context) Line 783	C++
 	libGLESv2.dll!egl::DestroyContext(void * dpy, void * ctx) Line 549	C++
 	[Inline Frame] xul.dll!mozilla::gl::GLLibraryEGL::fDestroyContext(void *) Line 257	C++
 	xul.dll!mozilla::gl::GLContextEGL::~GLContextEGL() Line 246	C++
 	[External Code]	
 	xul.dll!mozilla::detail::GenericRefCounted<0>::Release() Line 98	C++
 	xul.dll!mozilla::WebGLContext::DestroyResourcesAndContext() Line 314	C++
 	xul.dll!mozilla::WebGLContext::~WebGLContext() Line 208	C++
 	[External Code]	
 	xul.dll!nsSVGFilterChainObserver::DeleteCycleCollectable() Line 277	C++
 	xul.dll!AsyncScriptLoader::cycleCollection::DeleteCycleCollectable(void * p) Line 253	C++
 	xul.dll!SnowWhiteKiller::~SnowWhiteKiller() Line 2655	C++
 	xul.dll!nsCycleCollector::FreeSnowWhite(bool aUntilNoSWInPurpleBuffer) Line 2839	C++
 	xul.dll!nsCycleCollector_doDeferredDeletion() Line 4132	C++
 	xul.dll!AsyncFreeSnowWhite::Run() Line 146	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 1265	C++
 	xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 389	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 96	C++
 	xul.dll!mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate * aDelegate) Line 301	C++
 	xul.dll!MessageLoop::RunHandler() Line 232	C++
 	xul.dll!MessageLoop::Run() Line 212	C++
 	xul.dll!nsBaseAppShell::Run() Line 158	C++
 	xul.dll!nsAppShell::Run() Line 271	C++
 	xul.dll!XRE_RunAppShell() Line 869	C++
 	xul.dll!mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate * aDelegate) Line 278	C++
 	xul.dll!MessageLoop::RunHandler() Line 232	C++
 	xul.dll!MessageLoop::Run() Line 212	C++
 	xul.dll!XRE_InitChildProcess(int aArgc, char * * aArgv, const XREChildData * aChildData) Line 697	C++
 	xul.dll!mozilla::BootstrapImpl::XRE_InitChildProcess(int argc, char * * argv, const XREChildData * aChildData) Line 65	C++
 	firefox.exe!content_process_main(mozilla::Bootstrap * bootstrap, int argc, char * * argv) Line 64	C++
 	firefox.exe!NS_internal_main(int argc, char * * argv, char * * envp) Line 289	C++
 	firefox.exe!wmain(int argc, wchar_t * * argv) Line 118	C++
 	[External Code]	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

I'm not sure if this is our regression or if it's from an ANGLE update. Is anyone still investigating this crash?

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #6)
> I'm not sure if this is our regression or if it's from an ANGLE update. Is
> anyone still investigating this crash?

Doesn't look like it's from the most recent ANGLE update, but it may have been from an earlier one, or at least the frequency may have been increased.
Nobody is currently spending a lot of time on this, with the low frequency of crashes we have.

Comment 8

[Marcia Knous [:marcia]]

No recent crashes. Resolving as WFM.