Bug 138539

Summary: Fix various cases of incorrect cross-thread capture of non-thread-safe RefCounted
Product: WebKit Reporter: Darin Adler <darin>
Component: WebCore Misc.Assignee: Darin Adler <darin>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, commit-queue, koivisto, zan
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch ap: review+

Description Darin Adler 2014-11-08 18:15:22 PST
Fix various cases of incorrect cross-thread capture of non-thread-safe RefCounted
Comment 1 Darin Adler 2014-11-08 18:19:51 PST
Created attachment 241243 [details]
Patch
Comment 2 Darin Adler 2014-11-08 18:20:51 PST
This covers all the places I could find trying to use isolatedCopy to capture something and pass it to a new thread, but dealing with the last deref on the main thread incorrectly.
Comment 3 WebKit Commit Bot 2014-11-08 18:23:15 PST
Attachment 241243 [details] did not pass style-queue:


ERROR: Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.cpp:332:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Total errors found: 1 in 10 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 4 Alexey Proskuryakov 2014-11-08 18:54:53 PST
Comment on attachment 241243 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=241243&action=review

> Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.cpp:421
> +    StringCapture capturedURL(url.string());

This idiom makes URL forget that it was invalid - we get a string, and then push it back into a URL without checks.

I think that we need to explicitly check for url being valid here and everywhere else.
Comment 5 Alexey Proskuryakov 2014-11-08 19:11:00 PST
Or better yet, introduce a URLCapture class.
Comment 6 Darin Adler 2014-11-08 20:36:06 PST
I’ll add URLCapture.
Comment 7 Darin Adler 2014-11-08 21:00:05 PST
Created attachment 241247 [details]
Patch
Comment 8 WebKit Commit Bot 2014-11-08 21:01:19 PST
Attachment 241247 [details] did not pass style-queue:


ERROR: Source/WebCore/Modules/websockets/WorkerThreadableWebSocketChannel.cpp:332:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Total errors found: 1 in 13 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 9 Alexey Proskuryakov 2014-11-08 21:37:11 PST
Comment on attachment 241247 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=241247&action=review

Very nice!

> Source/WebCore/platform/URL.h:269
> +    URL releaseURL();

This function ended up unused, would you still like to keep it?

> Source/WebCore/platform/URL.h:272
> +    void operator=(const URLCapture&) = delete;

It is unusual to have a copy constructor, but delete operator=. I'm not sure if that's legitimate.
Comment 10 Darin Adler 2014-11-09 09:18:16 PST
Comment on attachment 241247 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=241247&action=review

>> Source/WebCore/platform/URL.h:269
>> +    URL releaseURL();
> 
> This function ended up unused, would you still like to keep it?

I simply copied StringCapture. I think the two should stay in sync, but I am not sure if either needs this. I think we should have either url() or releaseURL(), but I don’t think we need both.

>> Source/WebCore/platform/URL.h:272
>> +    void operator=(const URLCapture&) = delete;
> 
> It is unusual to have a copy constructor, but delete operator=. I'm not sure if that's legitimate.

I simply copied StringCapture. I think the two should stay in sync.

I don’t feel strongly about this design issue; it’s a little arbitrary to not have operator=, but seems OK to me. Note that the only reason we have a copy constructor in this class is because that’s what’s used to capture. If we could make it legal only for capture and make any other copying illegal, I think we would do that.
Comment 11 Darin Adler 2014-11-09 09:25:24 PST
Committed r175792: <http://trac.webkit.org/changeset/175792>
Comment 12 Antti Koivisto 2014-11-09 15:15:03 PST
(In reply to comment #10)
> I don’t feel strongly about this design issue; it’s a little arbitrary to
> not have operator=, but seems OK to me. Note that the only reason we have a
> copy constructor in this class is because that’s what’s used to capture. If
> we could make it legal only for capture and make any other copying illegal,
> I think we would do that.

Right, I tried to make it harder to use this class for anything else beyond capturing.
Comment 13 Alexey Proskuryakov 2014-11-09 16:08:11 PST
I was thinking about the rule of three <http://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming)>.

I certainly don't feel strongly about this at all. If there is anything to change here, it's probably to delete operator=(URLCapture&&) as well.