1431520 - Crash in shutdownhang | js::NukeCrossCompartmentWrappers

Status: RESOLVED DUPLICATE of bug 816784

(Core :: JavaScript Engine, defect, P5)

Description

[Robert Hartmann]

Firefox 52.5.3esr
Windows XP SP3 , 32bit

Socorro lost my user comment:

closing Firefox with this tabs open:
website https://mydrive.tomtom.com/de_de/
and 
website https://www.tomtommaps.com/livetraffic/

=============================================================
This bug was filed from the Socorro interface and is
report bp-d74f0b45-b887-48fb-bc85-902f50180118.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll js::NukeCrossCompartmentWrappers js/src/proxy/CrossCompartmentWrapper.cpp:522
1 xul.dll nsXPCComponents_Utils::NukeSandbox js/xpconnect/src/XPCComponents.cpp:3025
2 xul.dll NS_InvokeByIndex xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_msvc.asm:54
3 xul.dll XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1344
4 xul.dll XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1000
5 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:459
6 xul.dll InternalCall js/src/vm/Interpreter.cpp:504
7 xul.dll Interpret js/src/vm/Interpreter.cpp:2922
8 xul.dll js::RunScript js/src/vm/Interpreter.cpp:405
9 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:477

=============================================================

Comment 1

[Stefan [:StefanG_QA]]

Based on other similar crashes I think the correct component is Core::JavaScript Engine.

Comment 2

[Jason Orendorff [:jorendorff]]

Started abruptly on December 27. See bug 1430972. But this flavor happens only on ESR52.

As it happens, we shipped FIREFOX_52_5_3esr_RELEASE at some point after 2017-12-26 08:38 +0000. That's the push timestamp of this changeset: <https://hg.mozilla.org/releases/mozilla-esr52/rev/292a2d5bcb1f>.

<https://product-details.mozilla.org/1.0/firefox.json> gives the release date of "firefox-52.5.2esr" as 	"2017-12-28" (date only, no time or time zone).

Comment 3

[Andrew McCreight [:mccr8]]

Bug 816784 made NukeCrossCompartmentWrappers much faster, but that only landed in 55. I don't think it meets the criteria for backporting to ESR.

Comment 4

[Jason Orendorff [:jorendorff]]

Hmm. It looks like the only new thing in 52.5.3 was a change to the crash reporter.

https://hg.mozilla.org/releases/mozilla-esr52/graph/292a2d5bcb1f

So perhaps this caused crashes to be reported that were previously being blocked or dropped? mconley can tell us.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Don't forget that we purged all the old crash data in late December due to the aforementioned crash reporter issues.

Comment 6

[Jason Orendorff [:jorendorff]]

Oh, we're done then. This is ESR-only and we have no other leads.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jason Orendorff [:jorendorff] from comment #4)
> Hmm. It looks like the only new thing in 52.5.3 was a change to the crash
> reporter.
> 
> https://hg.mozilla.org/releases/mozilla-esr52/graph/292a2d5bcb1f
> 
> So perhaps this caused crashes to be reported that were previously being
> blocked or dropped? mconley can tell us.

I suspect this only appeared abruptly because, as RyanVM noted, we nuked all of the old crash data right around then.

The client-side stackwalking crash ping data (which, as far as I can tell, is not accessible by any UI for analysis just yet) could probably help confirm this.