TextDirectiveFinder and TextDirectiveCreator should use ref pointers for mDocument
Categories
(Core :: DOM: Core & HTML, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox142 | --- | fixed |
People
(Reporter: mccr8, Assigned: jjaschke)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
TextDirectiveFinder and TextDirectiveCreator effectively use raw pointers for their mDocument fields. This is very dodgy because unless the classes are used very carefully this could lead to a use-after-free. I'm pretty sure they are actually okay because they are used in a stacklike way, although they are heap allocated so we can't mark them MOZ_STACK_CLASS. However, the tiny overhead that is saved by making these a raw pointer instead of RefPtr<Document>
doesn't seem like it is worth the risk, so I think we should change these fields to a strong pointer.
Reporter | ||
Comment 1•3 months ago
|
||
Jan, could you take a look at this? Probably the biggest hassle here will be changing mDocument.
to mDocument->
everywhere. Thanks.
Reporter | ||
Updated•3 months ago
|
Assignee | ||
Comment 2•3 months ago
|
||
The only way where this situation could occur is if these classes were used in new places in the code. TextDirectiveCreator
has a protected constructor, its only public API is a static function, nothing can run script; therefore I think it's impossible for its Document
reference to point to something deleted throughout its existence. Arguably, TextDirectiveFinder
should get a private constructor + friend FragmentDirective
to make sure it's not used outside of FragmentDirective
(which keeps Document
alive).
The motivation for this pattern was not performance, but instead documenting that Document
is non-null through code (this way all users of mDocument
wouldn't have to null-check).
However, this is a relatively weak argument. :) Therefore, patch attached.
Assignee | ||
Comment 3•3 months ago
|
||
Updated•3 months ago
|
Backed out for causing build bustages @TextDirectiveCreator.cpp.
Reporter | ||
Comment 7•3 months ago
|
||
It looks like removing the redundant MOZ_ASSERT on nullness isn't optional!
Assignee | ||
Updated•3 months ago
|
Comment 9•2 months ago
|
||
bugherder |
Updated•2 months ago
|
Description
•