RESOLVED FIXED 67906
Use of static RefPtr in FontPlatformData causes global destructor ordering problems
https://bugs.webkit.org/show_bug.cgi?id=67906
Summary Use of static RefPtr in FontPlatformData causes global destructor ordering pr...
Marshall Greenblatt
Reported 2011-09-11 14:13:34 PDT
From WebKit/Source/WebCore/platform/graphics/chromium/FontPlatformDataChromiumWin.cpp: FontPlatformData::RefCountedHFONT* FontPlatformData::hashTableDeletedFontValue() { static RefPtr<RefCountedHFONT> deletedValue = RefCountedHFONT::create(reinterpret_cast<HFONT>(-1)); return deletedValue.get(); } The problem with using static RefPtr is that, on Windows, the destructor of |deletedValue| will not be called until doexit() is executed on the main application thread. In single-process applications (like Chromium Embedded Framework) the main application thread may not be the same as the WebKit thread. This problem was exposed by WebKit revision 92254 which adds asserts to RefCounted to make sure ref/deref happens on the right thread. According to the WebKit experts the correct solution is to intentionally leak the static RefCountedHFONT object using leakRef().
Attachments
Proposed fix for bug 67906. (1.62 KB, patch)
2011-09-11 14:18 PDT, Marshall Greenblatt
no flags
Proposed fix for bug 67906. (1.49 KB, patch)
2011-09-11 14:24 PDT, Marshall Greenblatt
abarth: review-
Proposed Fix #3 (1.56 KB, patch)
2011-09-12 06:23 PDT, Marshall Greenblatt
no flags
Marshall Greenblatt
Comment 1 2011-09-11 14:18:54 PDT
Created attachment 107007 [details] Proposed fix for bug 67906. Please review the attached bug_67906.patch.
Marshall Greenblatt
Comment 2 2011-09-11 14:24:31 PDT
Created attachment 107008 [details] Proposed fix for bug 67906. Please review the attached patch.
Adam Barth
Comment 3 2011-09-11 20:38:48 PDT
Comment on attachment 107008 [details] Proposed fix for bug 67906. This looks fine, but we should use DECLARE_STATIC_LOCAL though (and I would merge those too lines together).
Marshall Greenblatt
Comment 4 2011-09-12 06:23:37 PDT
Created attachment 107045 [details] Proposed Fix #3 Changed to use DEFINE_STATIC_LOCAL.
Marshall Greenblatt
Comment 5 2011-09-12 06:28:58 PDT
(In reply to comment #4) > Created an attachment (id=107045) [details] > Proposed Fix #3 > > Changed to use DEFINE_STATIC_LOCAL. Note: The above patch doesn't use leakRef() in combination with DEFINE_STATIC_LOCAL. This is because DEFINE_STATIC_LOCAL is already leaking a RefPtr that is holding a reference to the object, so I don't believe it's necessary to additionally call leakRef().
Marshall Greenblatt
Comment 6 2011-09-20 13:50:25 PDT
(In reply to comment #3) > (From update of attachment 107008 [details]) > This looks fine, but we should use DECLARE_STATIC_LOCAL though (and I would merge those too lines together). Hi Adam, can you review the updated patch? Thanks.
Adam Barth
Comment 7 2011-09-20 14:02:32 PDT
Comment on attachment 107045 [details] Proposed Fix #3 Looks great. Sorry for dropping the ball.
WebKit Review Bot
Comment 8 2011-09-20 15:38:43 PDT
Comment on attachment 107045 [details] Proposed Fix #3 Clearing flags on attachment: 107045 Committed r95576: <http://trac.webkit.org/changeset/95576>
WebKit Review Bot
Comment 9 2011-09-20 15:38:49 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.