Closed
Bug 1267696
Opened 6 years ago
Closed 6 years ago
startup crash in js::wasm::EnsureSignalHandlersInstalled with gdata in firefox 46
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: philipp, Unassigned)
References
Details
(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)
Comment 2•6 years ago
|
||
Windows 10 crash in AddVectoredExceptionHandler...
Flags: needinfo?(nihsanullah) → needinfo?(luke)
Comment 3•6 years ago
|
||
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.
![]() |
||
Comment 4•6 years ago
|
||
In FF46, the function was renamed from js::EnsureSignalHandlersInstalled to js::wasm::EnsureSignalHandlers. It seems like there are also crashes in FF45 and before: https://crash-stats.mozilla.com/signature/?signature=js%3A%3AEnsureSignalHandlersInstalled 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 (http://scrammed.blogspot.com/2014/03/reversing-emets-eaf-and-couple-of.html) 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: https://blog.gdatasoftware.com/2015/10/24294-g-data-exploit-protection-effectively-prevents-attacks-by-infected-magento-shops 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)
Reporter | ||
Updated•6 years ago
|
No longer blocks: 1229642
Keywords: regression
Reporter | ||
Comment 5•6 years ago
|
||
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...").
Comment 6•6 years ago
|
||
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.
Reporter | ||
Comment 7•6 years ago
|
||
thanks for the quick response. i'll file a separate bug in regards to hitman pro.
Comment 8•6 years ago
|
||
For reference, philipp filed bug 1268025 for the Hitman Pro crashes.
Reporter | ||
Comment 9•6 years ago
|
||
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.
Status: NEW → RESOLVED
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
You need to log in
before you can comment on or make changes to this bug.
Description
•