Accessing ContentProcessMessageManager::SharedData early during process startup crashes
Categories
(Core :: DOM: Content Processes, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
Details
Attachments
(1 file)
While working on bug 1620248, I'm triggering a crash around Services.cpmm.sharedData
.
When accessing it very early during process startup, firefox crashes on this line:
https://searchfox.org/mozilla-central/rev/670e13b51d272125c76a1bf84b9f3707583cde12/dom/base/ContentProcessMessageManager.cpp#45
return do_AddRef(child->SharedData());
because child->SharedData()
returns null.
That's because mSharedData
from ContentChild is still null:
https://searchfox.org/mozilla-central/rev/670e13b51d272125c76a1bf84b9f3707583cde12/dom/ipc/ContentChild.h#151
Very likely, this function isn't called yet:
https://searchfox.org/mozilla-central/rev/670e13b51d272125c76a1bf84b9f3707583cde12/dom/ipc/ContentChild.cpp#2359
mSharedData =
new SharedMap(ContentProcessMessageManager::Get()->GetParentObject(),
aMapFile, aMapSize, std::move(blobImpls));
Also likely because this ContentParent code:
https://searchfox.org/mozilla-central/rev/670e13b51d272125c76a1bf84b9f3707583cde12/dom/ipc/ContentParent.cpp#2717-2720
is called a bit late after the content process already started.
There is two underlying issues here:
- ContentProcessMessageManager.sharedData IDL:
https://searchfox.org/mozilla-central/source/dom/chrome-webidl/MessageManager.webidl#499
mentions a non-null attribute, whereas here, it is null if accessed early - May be
sharedData
should be set earlier? Or we should have an explicit event fired when it is set for the first time?
Here I'm going to at least allow this attribute to be null without crashing.
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Comment 3•4 years ago
|
||
bugherder |
Description
•