1379375 - Crash in mozilla::ProcessHangMonitor::Dispatch

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-87fd9ea4-36a2-456b-8297-1c6c00170707.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::ProcessHangMonitor::Dispatch(already_AddRefed<nsIRunnable>) 	dom/ipc/ProcessHangMonitor.cpp:1190
1 	xul.dll 	CreateHangMonitorParent 	dom/ipc/ProcessHangMonitor.cpp:1162
2 	xul.dll 	mozilla::ProcessHangMonitor::AddProcess(mozilla::dom::ContentParent*) 	dom/ipc/ProcessHangMonitor.cpp:1225
3 	xul.dll 	mozilla::dom::ContentParent::LaunchSubprocess(mozilla::hal::ProcessPriority) 	dom/ipc/ContentParent.cpp:2072
4 	xul.dll 	mozilla::dom::ContentParent::GetNewOrUsedBrowserProcess(nsAString const&, mozilla::hal::ProcessPriority, mozilla::dom::ContentParent*) 	dom/ipc/ContentParent.cpp:874
5 	xul.dll 	mozilla::dom::ContentParent::CreateBrowser(mozilla::dom::TabContext const&, mozilla::dom::Element*, mozilla::dom::ContentParent*, mozilla::dom::TabParent*, unsigned __int64) 	dom/ipc/ContentParent.cpp:1218
6 	xul.dll 	nsFrameLoader::TryRemoteBrowser() 	dom/base/nsFrameLoader.cpp:3001
7 	xul.dll 	nsFrameLoader::ShowRemoteFrame(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, nsSubDocumentFrame*) 	dom/base/nsFrameLoader.cpp:1258
8 	xul.dll 	nsFrameLoader::Show(int, int, int, int, nsSubDocumentFrame*) 	dom/base/nsFrameLoader.cpp:1112
9 	xul.dll 	nsSubDocumentFrame::ShowViewer() 	layout/generic/nsSubDocumentFrame.cpp:185
10 	xul.dll 	AsyncFrameInit::Run() 	layout/generic/nsSubDocumentFrame.cpp:92
11 	xul.dll 	nsDocument::EndUpdate(unsigned int) 	dom/base/nsDocument.cpp:5093
12 	xul.dll 	nsHTMLDocument::EndUpdate(unsigned int) 	dom/html/nsHTMLDocument.cpp:2495
13 	xul.dll 	mozAutoDocUpdate::~mozAutoDocUpdate() 	dom/base/mozAutoDocUpdate.h:40
14 	xul.dll 	nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) 	dom/base/nsINode.cpp:2520
15 	xul.dll 	mozilla::dom::NodeBinding::appendChild 	obj-firefox/dom/bindings/NodeBinding.cpp:856
16 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:470
17 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:515
18 	xul.dll 	js::Wrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) 	js/src/proxy/Wrapper.cpp:166
19 	xul.dll 	js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) 	js/src/proxy/CrossCompartmentWrapper.cpp:353
20 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:452
21 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:515
22 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:3064
23 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:410
24 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:488
25 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:515
26 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:3064
27 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:410
28 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:488
29 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:515
30 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:3064
31 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:410
32 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:488
33 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:515
34 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp:3064
35 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp:410
36 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:488
37 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:515
38 	xul.dll 	AsyncFunctionResume 	js/src/vm/AsyncFunction.cpp:189
39 	xul.dll 	js::AsyncFunctionAwaitedFulfilled(JSContext*, JS::Handle<js::PromiseObject*>, JS::Handle<JS::Value>, JS::Handle<JS::Value>) 	js/src/vm/AsyncFunction.cpp:216
40 	xul.dll 	AsyncFunctionAwaitPromiseReactionJob 	js/src/builtin/Promise.cpp:879
41 	xul.dll 	PromiseReactionJob 	js/src/builtin/Promise.cpp:962

crash reports with this signature are newly appearing in 55 and later apparently with the work from bug 1366845.

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Bill, this seemed regress from bug 1366845. Could you please take a look at this?

Comment 2

[(Away)]

Looks like an OOM somewhere; the reports have alarmingly low levels of virtual and/or physical memory available.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Yeah, this seems like an OOM. Thread stacks require a pretty big contiguous allocation, so it wouldn't be too surprising to OOM here. However, I don't see any crashes before my change. I wonder if Chromium thread stacks are bigger than NSPR thread stacks by default?

Comment 4

[Mike Taylor [:miketaylr]]

Gonna fix-optional for 55 due to low crash volume.

Comment 5

[Maire Reavy [:mreavy]]

Clearly thread creation failed.  WONTFIX for 55 and 56

Comment 6

[(no longer active)]

(In reply to Bill McCloskey (:billm) from comment #3)
> I wonder if Chromium thread stacks are
> bigger than NSPR thread stacks by default?

The code before and after didn't pass a size: https://hg.mozilla.org/mozilla-central/rev/4ebcfc217300#l1.458

Both Chromium and NSPR pass in the stack size argument (which defaults to 0) down to CreateThread/_beginthreadex:

https://searchfox.org/mozilla-central/rev/f6dc0e40b51a37c34e1683865395e72e7fca592c/nsprpub/pr/src/md/windows/ntthread.c#180
https://searchfox.org/mozilla-central/rev/f6dc0e40b51a37c34e1683865395e72e7fca592c/ipc/chromium/src/base/platform_thread_win.cc#86

So the stack sizes are the same here.  Also if you look at http://bit.ly/2xB1J6W, you'll see that most of the crashes happening in the past 7 weeks happen with a lot of available memory.

One difference before and after the change here is that NSPR calls ResumeThread() whereas Chromium doesn't.

Comment 7

[BugBot [:suhaib / :marco]]

Closing because no crashes reported for 12 weeks.