Closed
Bug 1379375
Opened 7 years ago
Closed 4 years ago
Crash in mozilla::ProcessHangMonitor::Dispatch
Categories
(Core :: DOM: Content Processes, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | wontfix |
firefox56 | --- | wontfix |
firefox57 | --- | wontfix |
People
(Reporter: philipp, Unassigned)
References
Details
(Keywords: crash, regression)
Crash Data
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•7 years ago
|
||
Hi Bill, this seemed regress from bug 1366845. Could you please take a look at this?
Flags: needinfo?(wmccloskey)
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?
Comment 4•7 years ago
|
||
Gonna fix-optional for 55 due to low crash volume.
Flags: needinfo?(wmccloskey)
Comment 5•7 years ago
|
||
Clearly thread creation failed. WONTFIX for 55 and 56
Comment 6•7 years 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•7 years ago
|
Priority: -- → P3
Updated•7 years ago
|
Comment 7•4 years ago
|
||
Closing because no crashes reported for 12 weeks.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•