[webkit-changes] [WebKit/WebKit] 08cf48: [ Ventura Debug WK2 arm64 EWS ] ASSERTION FAILED: ...

[Jean-Yves Avenard]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 08cf48f399ffdf6357e45edb8bc7f47b303a8b18
      https://github.com/WebKit/WebKit/commit/08cf48f399ffdf6357e45edb8bc7f47b303a8b18
  Author: Jean-Yves Avenard <jya at apple.com>
  Date:   2024-02-22 (Thu, 22 Feb 2024)

  Changed paths:
    M LayoutTests/platform/mac-ventura/TestExpectations
    M LayoutTests/platform/mac-wk1/TestExpectations
    M Source/WebCore/platform/network/cocoa/WebCoreNSURLSession.h
    M Source/WebCore/platform/network/cocoa/WebCoreNSURLSession.mm

  Log Message:
  -----------
  [ Ventura Debug WK2 arm64 EWS ] ASSERTION FAILED: m_shutdown in WebKit::RemoteMediaResource::~RemoteMediaResource() seen with http/tests/media/hls/track-in-band-multiple-cues.html
https://bugs.webkit.org/show_bug.cgi?id=269403
rdar://122967706

Reviewed by Youenn Fablet.

Following 273804 at main, a PlatformMediaResource is accessed on the MediaResourceLoader's target.
The AVPlayer runs on its own thread while the MediaPlayer runs in the main thread.

As such, we can have concurrent, and conflicting access to the MediaResource from both the AVPlayer
and the MediaPlayer.

The MediaPlayer could be shutting down, cancelling the WebCoreNSURLSessionDataTask, while the
AVPlayer is attempting to suspend and the resume download.

Under such circumstances we had two issues:
1- It was possible that following a cancel, a suspend be received, this would trigger a second
call to `loadFinishedWithError` which would assert as the task hasn't already been removed from
the map
2- If the task was cancelled while we were in the middle of resume operation the newly allocated
resource woulb be deleted without first being shutdown.

For 1) We check that the previous task's state wasn't NSURLSessionTaskStateCompleted and abort if so.
For 2) We check that the task's state hasn't changed mid-way and if so shutdown the resource and stop.

Another issue resolved here, is that it was possible for the MediaResource to call its client with
data immediately after creation, before the session had finished being setup, if so the callback
would be ignored which resulted in some tests intermittently timing out.
We now set the MediaSource's client immediately and allow processing the callbacks (this resolves
bug 259485).

We also change the structure so that the task's resource is only ever accessed on the loader's tarket.
We can remove the locking operation around the resource access as a result.

Covered by existing tests.
* LayoutTests/platform/mac-ventura/TestExpectations:
* Source/WebCore/platform/network/cocoa/WebCoreNSURLSession.h:
* Source/WebCore/platform/network/cocoa/WebCoreNSURLSession.mm:
(-[WebCoreNSURLSessionDataTask resource]):
(-[WebCoreNSURLSessionDataTask setResource:]):
(-[WebCoreNSURLSessionDataTask suspend]):
(-[WebCoreNSURLSessionDataTask resume]):
(-[WebCoreNSURLSessionDataTask dealloc]):

Canonical link: https://commits.webkit.org/275217@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications