Bug 221891 - ThreadMessageReceiverRefCounted subclasses are accessed in non-thread-safe way
Summary: ThreadMessageReceiverRefCounted subclasses are accessed in non-thread-safe way
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Kimmo Kinnunen
URL:
Keywords: InRadar
Depends on:
Blocks: 221560
  Show dependency treegraph
 
Reported: 2021-02-15 02:10 PST by Kimmo Kinnunen
Modified: 2021-02-18 07:59 PST (History)
9 users (show)

See Also:


Attachments
Patch (23.51 KB, patch)
2021-02-15 02:20 PST, Kimmo Kinnunen
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (22.68 KB, patch)
2021-02-15 02:28 PST, Kimmo Kinnunen
no flags Details | Formatted Diff | Diff
update names (23.11 KB, patch)
2021-02-16 00:15 PST, Kimmo Kinnunen
no flags Details | Formatted Diff | Diff
update names (23.11 KB, patch)
2021-02-16 00:16 PST, Kimmo Kinnunen
no flags Details | Formatted Diff | Diff
Patch (23.13 KB, patch)
2021-02-18 02:01 PST, Kimmo Kinnunen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kimmo Kinnunen 2021-02-15 02:10:11 PST
ThreadMessageReceiverRefCounted subclasses are accessed in non-thread-safe way

The subclasses call Connection::addThreadMessageReceiver() during their construction, passing 'this' as the receiver.
The virtual function pointer is not fully constructed during the call time.
Connection may start dispatching calls through that pointer immediately after the call.
If a message comes during the call, it may be dispatched during the subclass constructor still running, before the virtual function pointer being correctly set up. 
Accessing virtual function pointer is not thread safe until it is fully constructed.

The subclasses call Connection::removeThreadMessageReceiver() during their destruction.
Connection may still dispatch calls through the passed in virtual function pointer. The virtual pointer is not as expected anymore at that point, is not thread-safe to read.
Upon dispatch, the connection will ref the ThreadMessageReceiver.  Since the instance might already be in destructor, this is a ref count increase on a destroyed object.
Comment 1 Kimmo Kinnunen 2021-02-15 02:20:12 PST
Created attachment 420290 [details]
Patch
Comment 2 Kimmo Kinnunen 2021-02-15 02:28:49 PST
Created attachment 420291 [details]
Patch
Comment 3 Chris Dumez 2021-02-15 10:49:11 PST
Comment on attachment 420291 [details]
Patch

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

r=me with nits.

> Source/WebKit/GPUProcess/webrtc/RemoteAudioMediaStreamTrackRendererManager.cpp:46
> +void RemoteAudioMediaStreamTrackRendererManager::connectGPUProcess()

I don't understand why this is named connectGPUProcess(). This code runs in the GPUProcess and if anything, it starts listening for IPC from the WebProcess. I think we should find a better name. Maybe startListeningForIPC()?

> Source/WebKit/GPUProcess/webrtc/RemoteAudioMediaStreamTrackRendererManager.h:66
> +    void disconnectGPUProcess();

What's this? Can't find the definition.

> Source/WebKit/GPUProcess/webrtc/RemoteSampleBufferDisplayLayerManager.cpp:48
> +void RemoteSampleBufferDisplayLayerManager::connectGPUProcess()

Same comment about naming.

> Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp:98
> +void NetworkRTCProvider::connectWebProcess()

Same comment about naming.

> Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp:171
> +void LibWebRTCCodecs::connectGPUProcess()

Same comment about naming.

> Source/WebKit/WebProcess/cocoa/RemoteCaptureSampleManager.cpp:52
> +void RemoteCaptureSampleManager::disconnectGPUProcess()

Same comment about naming.
Comment 4 Kimmo Kinnunen 2021-02-16 00:15:11 PST
Created attachment 420429 [details]
update names
Comment 5 Kimmo Kinnunen 2021-02-16 00:16:33 PST
Created attachment 420430 [details]
update names
Comment 6 EWS 2021-02-16 05:58:53 PST
commit-queue failed to commit attachment 420430 [details] to WebKit repository. To retry, please set cq+ flag again.
Comment 7 EWS 2021-02-16 08:10:59 PST
Committed r272905: <https://commits.webkit.org/r272905>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 420430 [details].
Comment 8 Radar WebKit Bug Importer 2021-02-16 08:11:29 PST
<rdar://problem/74391824>
Comment 9 Truitt Savell 2021-02-17 13:51:16 PST
Reverted r272905 for reason:

caused TestWebKitAPI.WebKit2.CrashGPUProcessWhileCapturingAndCalling to timeout

Committed r273029 (234230@main): <https://commits.webkit.org/234230@main>
Comment 10 Kimmo Kinnunen 2021-02-18 02:01:59 PST
Created attachment 420813 [details]
Patch
Comment 11 Kimmo Kinnunen 2021-02-18 02:04:34 PST
Comment on attachment 420813 [details]
Patch

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

> Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp:-179
> -        m_connection->removeThreadMessageReceiver(Messages::LibWebRTCCodecsProxy::messageReceiverName());

This line was originally buggy..

> Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp:471
> +        m_connection->removeThreadMessageReceiver(Messages::LibWebRTCCodecs::messageReceiverName());

..and I managed to put the above line here.
Here in this patch this line is now correct and the test passes again
Comment 12 Kimmo Kinnunen 2021-02-18 05:00:43 PST
Comment on attachment 420813 [details]
Patch

Taking the liberty to carry the r+ over from the last patch, as the only thing that changed was the ReceiverName change from Proxy message to plain message.
Comment 13 EWS 2021-02-18 07:59:11 PST
Committed r273074: <https://commits.webkit.org/r273074>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 420813 [details].