No subject

CSSSegmentedFontFace has a HashMap where the values are SegmentedFontData*. These are not deleted by CSSSegmentedFontFace, which is good, but it is not clear that this table is always cleared when FontFallbackList prunes its tree. That would require calling CSSSegmentedFontFace::~CSSSegmentedFontFace(), CSSSegmentedFontFace::fontLoaded(CSSFontFace*) or CSSSegmentedFontFace::appendFontFace(PassRefPtr<CSSFontFace> fontFace). CSSFontFaceSource has identical issues to CSSSegmentedFontFace.

Who clears the HashMap in CSSSegmentedFontFace and CSSFontFaceSource when FontData is deleted? It must be the case that these objects must always destructed when the FontData is cleared. Otherwise we would see problems all over tha place that we do not see now.

GlyphPage holds an array of SimpleFontData*. This is cleared when fonts are purged from the GlyphPageTreeNode.

GlyphPageTreeNode holds a HashMap keyed on FontData*. Cleared in destructor and when font is purged.

SimpleFontData owns its derived font data and deletes it.

Are the SimpleFontData DerivedData members ever cached? No, allocated directly in platform layers, held in RefPtrs, and never held by anything else.

InlineFlowBox has a hash map of SimpleFontData (rendering). But this is only ever stack allocated.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.