Closed Bug 910376 Opened 8 years ago Closed 8 years ago
Table Hash Entry copy m Shared Blob Data and/or initialize m Shared Blob Data to null?
I'd normally ask about this on IRC, but the relevant people don't seem to be around at the moment. I noticed that FontTableHashEntry's copy constructor doesn't copy mSharedBlobData. This seems odd to me, because it means that if the hashtable is mutated, mSharedBlobData will be undefined. Similarly, mSharedBlobData is not initialized to null in the default FontTableHashEntry constructor, so I don't see how the |if (mSharedBlobData)| check in gfxFontEntry::FontTableHashEntry::Clear() and in SizeOfEntryExcludingThis() is sensible. OTOH this code is doing something clever with the hashtable that I don't grok, so maybe this is all right.
Thanks, Justin - this sure looks suspicious to me. I wonder if it might lie behind some of the unexplained font-related crashes we've seen over the past months, in bugs such as 875878 and 894798.
Oops... initializers were in the wrong order. Fixed that.
Attachment #798222 - Flags: review?(karlt)
Rebased and pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/f88c529008d0
Target Milestone: --- → mozilla26
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.