Potential font-instance leaks from gfxFontGroup::FindFontForChar
Categories
(Core :: Layout: Text and Fonts, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | --- | unaffected |
firefox82 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Noticed a couple of potential leaks resulting from the patch in bug 1371386. gfxFontGroup::FindFontForChar
returns a raw gfxFont
pointer without addref'ing, because in the great majority of cases, the caller will compare it to an existing pointer and see they're the same, and no new reference is needed. Therefore, we don't want to always addref fonts early, within FindFontForChar, as this causes a huge amount of extra refcount churn.
However, if FindFontForChar creates a font instance and then decides not to return it, because it subsequently finds a better match for the request, then it does need to take and release a reference to the gfxFont, because decrementing the refcount to zero is what tells the global font cache to start tracking the object for deferred deletion. If we fail to do this, the created-but-unused font can leak because the cache doesn't yet know about it.
In most cases this is handled correctly (e.g. see the use of autoRefDeref(candidateFont)
in the CheckCandidate lambda, to ensure we track a discarded candidate font for deletion, but there are a couple cases that were missed.
Assignee | ||
Comment 1•4 years ago
|
||
Depends on D88578
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Set release status flags based on info from the regressing bug 1371386
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•4 years ago
|
||
bugherder |
Description
•