Crash in mozilla::ProcessHangMonitor::Dispatch

NEW
Unassigned

Status

()

Core
DOM: Content Processes
P3
critical
3 months ago
23 days ago

People

(Reporter: philipp, Unassigned)

Tracking

({crash, regression})

55 Branch
All
Windows
crash, regression
Points:
---

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox54 unaffected, firefox55 wontfix, firefox56 wontfix, firefox57 affected)

Details

(crash signature)

(Reporter)

Description

3 months ago
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.
Hi Bill, this seemed regress from bug 1366845. Could you please take a look at this?
Flags: needinfo?(wmccloskey)

Comment 2

3 months ago
Looks like an OOM somewhere; the reports have alarmingly low levels of virtual and/or physical memory available.
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?
Gonna fix-optional for 55 due to low crash volume.
status-firefox55: affected → fix-optional

Updated

2 months ago
Flags: needinfo?(wmccloskey)
Clearly thread creation failed.  WONTFIX for 55 and 56
status-firefox55: fix-optional → wontfix
status-firefox56: affected → wontfix
status-firefox57: --- → affected

Comment 6

25 days ago
(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.

Updated

23 days ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.