Closed
Bug 1380106
Opened 7 years ago
Closed 7 years ago
stylo: Crash in do_QueryFrame::operator<T> nsIAnonymousContentCreator*
Categories
(Core :: CSS Parsing and Computation, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | --- | fixed |
People
(Reporter: marcia, Assigned: bholley)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
1.27 KB,
patch
|
heycam
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-88e599f9-e12a-4ba9-82d1-29b520170711. ============================================================= Seen in crash stats: http://bit.ly/2tFdqYl Some URLs: https://www.lineageoslog.com/build https://download.mokeedev.com/?device=hlte
Reporter | ||
Updated•7 years ago
|
Blocks: stylo-site-issues
Assignee | ||
Comment 1•7 years ago
|
||
So, I'm not really sure why do_QueryFrame is crashing, but given that this is during document teardown it seems possible that we may have destroyed the arena but not yet nulled out the element->frame pointer. Either way, we call FragmentOrElement::DestroyContent, which calls nsBindingManager::RemovedFromDocumentInternal, which calls FragmentOrElement::SetXBLInsertionParent, which tries to recursively clear servo data from the subtree: https://hg.mozilla.org/mozilla-central/annotate/0e41d07a703f/dom/base/FragmentOrElement.cpp#l1221 We really don't need to be doing that at all given that this is during teardown. So it might make sense to just clear the servo data at the top of FragmentOrElement::DestroyContent. I'll try.
Assignee: nobody → bobbyholley
Assignee | ||
Comment 2•7 years ago
|
||
MozReview-Commit-ID: 9ydkvlDA9oS
Attachment #8885427 -
Flags: review?(cam)
Assignee | ||
Comment 3•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=70de977c034515f3904dcd635d9dc7acbc2b855c
Comment 4•7 years ago
|
||
Comment on attachment 8885427 [details] [diff] [review] Drop style data in DestroyContent. v1 Review of attachment 8885427 [details] [diff] [review]: ----------------------------------------------------------------- I suppose this is OK, although I would prefer something less indirect, e.g. a check in FragmentOrElement::SetXBLInsertionParent that we're not in the middle of destroying the document (e.g. by checking nsDocument::mIsGoingAway, although that's not exposed).
Attachment #8885427 -
Flags: review?(cam) → review+
Updated•7 years ago
|
Priority: -- → P1
Assignee | ||
Comment 5•7 years ago
|
||
Boris was concerned as to why we'd be hitting this, and was going to try reproducing locally.
Flags: needinfo?(bzbarsky)
Comment 6•7 years ago
|
||
So I tried adding checks to FragmentOrElement::DestroyContent to yell if GetPrimaryFrame() is non-null. It never is, for me, on the urls in comment 0, as expected. I tried installing uBlock Origin (since the crash dump above seems to have it installed), but that does not seem to change things. Not sure whether one of the other addons is relevant here... Anyway, the change in this bug makes sense to me, I think, though I agree it fixing the bug is not quite obvious.
Flags: needinfo?(bzbarsky)
Pushed by bholley@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/795947f535e8 Drop style data in DestroyContent. r=heycam,r=bz
Comment 8•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/795947f535e8
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Updated•7 years ago
|
status-firefox54:
--- → unaffected
status-firefox55:
--- → unaffected
status-firefox-esr52:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•