Closed Bug 1267696 Opened 6 years ago Closed 6 years ago

startup crash in js::wasm::EnsureSignalHandlersInstalled with gdata in firefox 46


(Core :: JavaScript Engine: JIT, defect)

46 Branch
Windows NT
Not set



Tracking Status
firefox46 + affected
firefox47 --- affected


(Reporter: philipp, Unassigned)



(Keywords: crash)

Crash Data

[Tracking Requested - why for this release]:
regression & crash at startup

This bug was filed from the Socorro interface and is 
report bp-9390cdc1-73b0-4ae3-a4de-594422160422.
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 		@0x7ffa4e915a50 	
1 	xul.dll 	js::wasm::EnsureSignalHandlersInstalled(JSRuntime*) 	js/src/asmjs/WasmSignalHandlers.cpp
2 	xul.dll 	JSRuntime::init(unsigned int, unsigned int) 	js/src/vm/Runtime.cpp
3 	xul.dll 	JS_NewRuntime(unsigned int, unsigned int, JSRuntime*) 	js/src/jsapi.cpp
4 	xul.dll 	mozilla::CycleCollectedJSRuntime::CycleCollectedJSRuntime(JSRuntime*, unsigned int, unsigned int) 	xpcom/base/CycleCollectedJSRuntime.cpp
5 	xul.dll 	XPCJSRuntime::XPCJSRuntime(nsXPConnect*) 	js/xpconnect/src/XPCJSRuntime.cpp
6 	xul.dll 	XPCJSRuntime::newXPCJSRuntime(nsXPConnect*) 	js/xpconnect/src/XPCJSRuntime.cpp
7 	xul.dll 	nsXPConnect::nsXPConnect() 	js/xpconnect/src/nsXPConnect.cpp
8 	xul.dll 	nsXPConnect::InitStatics() 	js/xpconnect/src/nsXPConnect.cpp
9 	xul.dll 	Initialize() 	layout/build/nsLayoutModule.cpp
10 	xul.dll 	nsComponentManagerImpl::KnownModule::Load() 	xpcom/components/nsComponentManager.cpp
11 	xul.dll 	nsFactoryEntry::GetFactory() 	xpcom/components/nsComponentManager.cpp
12 	xul.dll 	nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) 	xpcom/components/nsComponentManager.cpp
13 	xul.dll 	nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**) 	xpcom/components/nsComponentManager.cpp
14 	xul.dll 	nsCOMPtr_base::assign_from_gs_contractid(nsGetServiceByContractID, nsID const&) 	xpcom/glue/nsCOMPtr.cpp
15 	xul.dll 	nsCOMPtr<nsISupports>::nsCOMPtr<nsISupports>(nsGetServiceByContractID) 	xpcom/glue/nsCOMPtr.h
16 	xul.dll 	NS_InitXPCOM2 	xpcom/build/XPCOMInit.cpp
17 	xul.dll 	ScopedXPCOMStartup::Initialize() 	toolkit/xre/nsAppRunner.cpp
18 	xul.dll 	XREMain::XRE_main(int, char** const, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp
19 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp
20 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp
21 	firefox.exe 	NS_internal_main(int, char**) 	browser/app/nsBrowserApp.cpp
22 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp
23 	firefox.exe 	__tmainCRTStartup 	f:/dd/vctools/crt/crtw32/startup/crt0.c:255
24 	kernel32.dll 	BaseThreadInitThunk 	
25 	ntdll.dll 	RtlUserThreadStart

this crash signature seems to be occurring since firefox 46 & only on windows 10 builds so far - it is a crash at startup. maybe it's related to the work in bug 1229642...
Sounds like a new startup crash on release; tracking for 46. 
Naveed can you pass this on to your team?
Flags: needinfo?(nihsanullah)
Windows 10 crash in AddVectoredExceptionHandler...
Flags: needinfo?(nihsanullah) → needinfo?(luke)
It looks like this also happened in 45.0.2 and earlier, but the signature was js::EnsureSignalHandlersInstalled.

Most crashes are EXCEPTION_ACCESS_VIOLATION_EXEC, that's a bit weird.
In FF46, the function was renamed from js::EnsureSignalHandlersInstalled to js::wasm::EnsureSignalHandlers.  It seems like there are also crashes in FF45 and before:
So I think this is an old crash signature unrelated to bug 1229642.

Clicking on 20 random crash reports for wasm::EnsureSignalHandlersInstalled, I see they all have a module ExploitProtection64.dll at the top of the list.  We've run into problems before (bug 1137050) where some security software (made by Microsoft in the case of bug 1137050) is disabling these calls (presumably to thwart some popular exploit tactic).  I don't think this is EMET (at least I don't see "emet" in the module list), but EMET does use AddVectoredExceptionHandler ( so it makes sense that it would guard itself by preventing any other calls from installing themselves "in front".  So maybe that's what ExploitProtection64.dll is doing.

Searching for "ExploitProtection64.dll" shows it's related to some G DATA Antivirus software which advertises exploit protection:
cc'ing Thomas Siebert from G Data who I happened to see commenting in a separate G Data bug (bug 1235537) in case he has any insights.
Flags: needinfo?(luke)
No longer blocks: 1229642
Keywords: regression
a couple of other EXCEPTION_ACCESS_VIOLATION_EXEC crashes like js::RegExpShared::execute & js::jit::EnterBaselineMethod seem to be quite frequent in early 46.0 data as well.

one module next to ExploitProtection.dll that is showing up time & time again in those reports is hmpalert.dll which seems to be part of HitmanPro.Alert ("...designed to stop threats before they emerge and aims to protect your vulnerable software, data and identity against current and future attacks, without requiring prior knowledge of the attack or malicious program...").
This bug is related to bug in an old version of our Exploit Protection and 64bit processes. As our affected version is pretty old there are not too many users involved - according to your crash statistics a small three-figure number. Nevertheless we just released a signature update that will mitigate this problem for users with old versions of our software.
thanks for the quick response. i'll file a separate bug in regards to hitman pro.
For reference, philipp filed bug 1268025 for the Hitman Pro crashes.
tentatively marking this bug as resolved by the update by gdata. though there still single occurrences of this signature, it's far less frequent in 46 release than it was during the 46 beta cycle still.
Closed: 6 years ago
Resolution: --- → WORKSFORME
Summary: startup crash in js::wasm::EnsureSignalHandlersInstalled in firefox 46 → startup crash in js::wasm::EnsureSignalHandlersInstalled with gdata in firefox 46
See Also: → 1399774
Duplicate of this bug: 1399774
You need to log in before you can comment on or make changes to this bug.