Closed
Bug 597212
Opened 14 years ago
Closed 14 years ago
hold a reference to language nsIAtom from gfxFontStyle
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla2.0b8
People
(Reporter: karlt, Assigned: karlt)
References
Details
Attachments
(2 files, 1 obsolete file)
2.22 KB,
patch
|
jfkthame
:
review+
joe
:
approval2.0+
|
Details | Diff | Splinter Review |
1.98 KB,
patch
|
jfkthame
:
review+
joe
:
approval2.0+
|
Details | Diff | Splinter Review |
gfxFontStyle doesn't keep references to the language nsIAtom. I don't know anything that ensures the pointer remains valid. nsRuleNode::ComputeVisibilityData ref-counts the result of do_GetAtom.
Assignee | ||
Comment 1•14 years ago
|
||
Attachment #476037 -
Flags: review?(jfkthame)
Assignee | ||
Comment 3•14 years ago
|
||
Forgot to remove another header. LookupLanguage is done in gfxFontGroup::ForEachFontInternal, anyway.
Attachment #476050 -
Attachment is obsolete: true
Attachment #476051 -
Flags: review?(jfkthame)
Attachment #476050 -
Flags: review?(jfkthame)
Comment 4•14 years ago
|
||
(In reply to comment #0) > gfxFontStyle doesn't keep references to the language nsIAtom. > I don't know anything that ensures the pointer remains valid. Hmm, my memory of this is a bit hazy but don't the language (or langGroup) atoms come from the language atom service's LookupLanguage() method, which ensures that all the atoms it returns will remain valid (because it owns references to them in its hashtable) until the service itself is shut down? And therefore the rest of the code can rely on these atoms being "permanent" once created.
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > ... don't the language (or langGroup) > atoms come from the language atom service's LookupLanguage() method LookupLanguage only returns langGroups, so real languages don't come from here.
Assignee | ||
Comment 6•14 years ago
|
||
nsLanguageAtomService::GetLanguageGroup uses languages as keys to nsInterfaceHashtable<nsISupportsHashKey, nsIAtom> mLangToGroup, but nsISupportsHashKey does not keep a reference.
Comment 7•14 years ago
|
||
Comment on attachment 476037 [details] [diff] [review] patch For now I suppose we'd better do this. If we could guarantee that language atoms are always persistent once they're created, we'd be able to avoid the overhead of refcount management here and simply pass the raw atom pointers around.
Attachment #476037 -
Flags: review?(jfkthame) → review+
Updated•14 years ago
|
Attachment #476051 -
Flags: review?(jfkthame) → review+
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #6) > nsLanguageAtomService::GetLanguageGroup uses languages as keys to > nsInterfaceHashtable<nsISupportsHashKey, nsIAtom> mLangToGroup, > but nsISupportsHashKey does not keep a reference. Oh, sorry. nsISupportsHashKey does keep a reference. However, I don't think we have any guarantee that GetLanguageGroup will be called for all gfxFontStyles.
Assignee | ||
Comment 9•14 years ago
|
||
Comment on attachment 476037 [details] [diff] [review] patch Requesting approval2.0 for the sake of attachment 476057 [details] [diff] [review] in bug 597147.
Attachment #476037 -
Flags: approval2.0?
Assignee | ||
Comment 10•14 years ago
|
||
Comment on attachment 476051 [details] [diff] [review] remove unnecessary extra nsILanguageAtomService::LookupLanguage Sensible related clean-up.
Attachment #476051 -
Flags: approval2.0?
Updated•14 years ago
|
Attachment #476037 -
Flags: approval2.0? → approval2.0+
Updated•14 years ago
|
Attachment #476051 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 11•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/420931108036 http://hg.mozilla.org/mozilla-central/rev/6e65aa67a0b3
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in
before you can comment on or make changes to this bug.
Description
•