Closed
Bug 1342810
Opened 7 years ago
Closed 7 years ago
Crash in xpc::NativeGlobal via ResolveRequestedModules
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla54
People
(Reporter: n.nethercote, Assigned: jonco)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
8.68 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-6d1259cd-2c42-4cc0-8a82-939d32170225. ============================================================= We've had crashes with this signature before (bug 1921535) but this is a different stack trace: > 0 xul.dll xpc::NativeGlobal(JSObject*) js/xpconnect/wrappers/WrapperFactory.cpp:674 > 1 xul.dll mozilla::dom::AutoJSAPI::Init(JSObject*) dom/base/ScriptSettings.cpp:488 > 2 xul.dll ResolveRequestedModules dom/base/nsScriptLoader.cpp:955 > 3 xul.dll nsScriptLoader::StartFetchingModuleDependencies(nsModuleLoadRequest*) dom/base/nsScriptLoader.cpp:1006 > 4 xul.dll mozilla::MozPromise<bool, nsresult, 0>::MethodThenValue<nsModuleLoadRequest, void ( nsModuleLoadRequest::*)(void), void ( nsModuleLoadRequest::*)(void)>::DoResolveOrRejectInternal(mozilla::MozPromise<bool, nsresult, 0>::ResolveOrRejectValue const&) obj-firefox/dist/include/mozilla/MozPromise.h:523 > 5 xul.dll mozilla::MozPromise<bool, nsresult, 0>::ThenValueBase::DoResolveOrReject(mozilla::MozPromise<bool, nsresult, 0>::ResolveOrRejectValue const&) obj-firefox/dist/include/mozilla/MozPromise.h:427 > 6 xul.dll mozilla::MozPromise<bool, nsresult, 0>::ThenValueBase::ResolveOrRejectRunnable::Run() obj-firefox/dist/include/mozilla/MozPromise.h:340 > 7 xul.dll mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run() obj-firefox/dist/include/mozilla/TaskDispatcher.h:193 > 8 xul.dll mozilla::EventTargetWrapper::Runner::Run() xpcom/threads/AbstractThread.cpp:164 > 9 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1264 It started spiking around Feb 22 and is the #4 top windows crash in Nightly 20170224030232, but there are some occurrences before that, e.g. Feb 11 or earlier. jonco, it looks related to JS modules -- can you please investigate? Crash address is always 0x0, so looks like |ms| is null.
Flags: needinfo?(jcoppeard)
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → jcoppeard
Flags: needinfo?(jcoppeard)
Assignee | ||
Comment 1•7 years ago
|
||
ResolveRequestedModules assumes the module script contains a non-null module record pointer. This is set to null if the module instantiation fails in nsModuleScript::SetInstantiationResult. We need to check if instantiation failed when we find up a previously loaded module in nsScriptLoader::WaitForModuleFetch.
Attachment #8841611 -
Flags: review?(bugs)
Updated•7 years ago
|
Attachment #8841611 -
Flags: review?(bugs) → review+
Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/8bf9111b7e9c Check for instantiation failure when a previously-loaded module is requested r=smaug
Comment 3•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/8bf9111b7e9c
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Updated•7 years ago
|
status-firefox52:
--- → disabled
status-firefox53:
--- → disabled
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•