WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
112762
Add an assertion to ensure AtomicString from two different threads are not compared
https://bugs.webkit.org/show_bug.cgi?id=112762
Summary
Add an assertion to ensure AtomicString from two different threads are not co...
Benjamin Poulain
Reported
2013-03-19 18:00:04 PDT
Add an assertion to ensure AtomicString from two different threads are not compared
Attachments
Patch
(12.46 KB, patch)
2013-03-19 18:03 PDT
,
Benjamin Poulain
no flags
Details
Formatted Diff
Diff
Patch
(12.97 KB, patch)
2013-06-27 14:49 PDT
,
Benjamin Poulain
ap
: review+
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from APPLE-EWS-5 for win-future
(817.09 KB, application/zip)
2013-06-28 16:48 PDT
,
Build Bot
no flags
Details
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Benjamin Poulain
Comment 1
2013-03-19 18:03:57 PDT
Created
attachment 193959
[details]
Patch
Benjamin Poulain
Comment 2
2013-03-19 18:07:58 PDT
A tiny step toward more safety debugging WebCore code with threads. I will have to modify WebCore accordingly (some HashTable use StringImpl* directly).
Eric Seidel (no email)
Comment 3
2013-03-19 18:11:56 PDT
YES I'm glad you're adding this. Sad that it's only turned on when that option is turned on. Maybe this should always be on for Debug?
Eric Seidel (no email)
Comment 4
2013-03-19 18:12:56 PDT
Also, be aware that abarth is in the process of making HTMLNames and friends static Atomic strings, which would allow them to be used in multiple AtomicStringTables, and potentially safe for x-thread compares.
Benjamin Poulain
Comment 5
2013-03-19 18:22:25 PDT
(In reply to
comment #3
)
> YES I'm glad you're adding this. Sad that it's only turned on when that option is turned on. Maybe this should always be on for Debug?
ASSERT_ATOMIC_STRINGIMPL_THREAD_CONSISTENCY is enabled on !ASSERT_DISABLED It will be enabled on the vast majority of debug builds. (In reply to
comment #4
)
> Also, be aware that abarth is in the process of making HTMLNames and friends static Atomic strings, which would allow them to be used in multiple AtomicStringTables, and potentially safe for x-thread compares.
I am really excited about that work actually :) When it lands, we will need to change the assertion accordingly (probably just add that a && b must be static).
Adam Barth
Comment 6
2013-03-19 18:42:29 PDT
This looks interesting. Would be willing to wait on landing this patch until after
https://bugs.webkit.org/show_bug.cgi?id=112769
lands?
Benjamin Poulain
Comment 7
2013-03-19 18:49:37 PDT
(In reply to
comment #6
)
> This looks interesting. Would be willing to wait on landing this patch until after
https://bugs.webkit.org/show_bug.cgi?id=112769
lands?
Not a problem. But I don't think the 2 patches conflicts. It will just be 1 more condition in the assertion + 1 more initialization in the constructor.
Adam Barth
Comment 8
2013-03-19 19:03:17 PDT
This patch assumes that a string impl is only ever in one atomic string table. That assumption might or might not remain true after my patch.
Benjamin Poulain
Comment 9
2013-06-27 14:49:36 PDT
Created
attachment 205639
[details]
Patch
Build Bot
Comment 10
2013-06-28 16:48:04 PDT
Comment on
attachment 205639
[details]
Patch
Attachment 205639
[details]
did not pass win-ews (win): Output:
http://webkit-queues.appspot.com/results/998356
New failing tests: fast/forms/select/popup-closes-on-blur.html
Build Bot
Comment 11
2013-06-28 16:48:07 PDT
Created
attachment 205757
[details]
Archive of layout-test-results from APPLE-EWS-5 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: APPLE-EWS-5 Port: win-future Platform: CYGWIN_NT-6.1-WOW64-1.7.20-0.266-5-3-i686-32bit
Alexey Proskuryakov
Comment 12
2013-07-15 12:52:15 PDT
Comment on
attachment 205639
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=205639&action=review
> Source/WTF/wtf/text/AtomicString.cpp:431 > + r->setAtomicStringTable(0);
Perhaps not part of this patch, but we really need to assert that we are not removing from the wrong table here.
> Source/WTF/wtf/text/AtomicStringImpl.h:48 > +ALWAYS_INLINE bool safeAtomicEqual(const AtomicStringImpl* a, const AtomicStringImpl* b)
I'm not a fan of "safe" names, they don't really explain much. Perhaps "equalWithThreadingAssertion"? Or just split the assertion into a separate function, and have callers invoke it explicitly before comparing pointers? The latter seems preferable to me.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug