Bug 206396 – [iOS] ServiceWorker process unexpectedly terminates on many tests, so they are reported as crash failures

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Service Workers

[David Kilzer (:ddkilzer)]

Layout test http/wpt/service-workers/third-party-cookie.html is a flakey crash on iOS Simulator:

Flakiness Dashboard:
<https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Fwpt%2Fservice-workers%2Fthird-party-cookie.html>

[Radar WebKit Bug Importer]

<rdar://problem/58670130>

[David Kilzer (:ddkilzer)]

External test results where this occurred:

<https://build.webkit.org/results/Apple%20iOS%2013%20Simulator%20Debug%20WK2%20(Tests)/r254469%20(1683)/results.html>

[Alexey Proskuryakov]

Newer results: https://build.webkit.org/results/Apple%20iPadOS%2013%20Simulator%20Debug%20WK2%20(Tests)/r254728%20(1061)/results.html

This is A LOT of crashes here! But looking at ~/Library/Logs/DiagnosticReports on the bot, I don't see any ServiceWorker crashes. So this it is probably unexpectedly exiting, not crashing.

[youenn fablet]

> This is A LOT of crashes here! But looking at
> ~/Library/Logs/DiagnosticReports on the bot, I don't see any ServiceWorker
> crashes. So this it is probably unexpectedly exiting, not crashing.

You might be right.
I wonder whether a service worker process whose last service worker is stopped (for instance it unregisters itself) will probably terminate itself and we might wrongly report it as a crash.

[youenn fablet]

(In reply to youenn fablet from comment #4)
> > This is A LOT of crashes here! But looking at
> > ~/Library/Logs/DiagnosticReports on the bot, I don't see any ServiceWorker
> > crashes. So this it is probably unexpectedly exiting, not crashing.
> 
> You might be right.
> I wonder whether a service worker process whose last service worker is
> stopped (for instance it unregisters itself) will probably terminate itself
> and we might wrongly report it as a crash.

Nope, as long as we do not close a WebSWContextManagerConnection, which is ordered by UIProcess, the process should not be terminating itself through AuxiliaryProcess::terminate.

[youenn fablet]

Since this is mostly Simulator Debug, it might be that SWContextManager::serviceWorkerFailedToTerminate is called after a timeout of either 10s or 100ms.
I'll add an ASSERT so that we can further debug that.

[David Kilzer (:ddkilzer)]

Is the binary that’s launched actually called “ServiceWorkerProcess” on disk, or is my memory correct that it’s actually a com.apple.WebKit.WebContent process binary that’s launched/configured in a special way and changes its name in `ps` and Activity Monitor?

If it’s the latter (a com.apple.WebKit.WebContent binary), then maybe we are looking for the wrong file name for crashes.  Have we tried matching up PIDs from stderr logging in test results to com.apple.WebKit.WebContent crash logs on disk (manually) to see if there is any correlation?

[Chris Dumez]

(In reply to David Kilzer (:ddkilzer) from comment #7)
> Is the binary that’s launched actually called “ServiceWorkerProcess” on
> disk, or is my memory correct that it’s actually a
> com.apple.WebKit.WebContent process binary that’s launched/configured in a
> special way and changes its name in `ps` and Activity Monitor?
> 
> If it’s the latter (a com.apple.WebKit.WebContent binary), then maybe we are
> looking for the wrong file name for crashes.  Have we tried matching up PIDs
> from stderr logging in test results to com.apple.WebKit.WebContent crash
> logs on disk (manually) to see if there is any correlation?

There is no ServiceWorkerProcess binary. A Service Worker process is a regular WebContent process (same binary as WebContent processes).

[Alexey Proskuryakov]

> If it’s the latter (a com.apple.WebKit.WebContent binary), then maybe we are looking for the wrong file name for crashes.

I was looking for the right file name for crashes on the bot. Automation may or may not be correct (not sure if I've seen a ServiceWorker crash log in test results yet), but that's irrelevant in the context of this bug.

[David Kilzer (:ddkilzer)]

(In reply to Alexey Proskuryakov from comment #9)
> > If it’s the latter (a com.apple.WebKit.WebContent binary), then maybe we are looking for the wrong file name for crashes.
> 
> I was looking for the right file name for crashes on the bot. Automation may
> or may not be correct (not sure if I've seen a ServiceWorker crash log in
> test results yet), but that's irrelevant in the context of this bug.

IDK, it seems relevant to me if run-webkit-tests isn't picking up existing crash logs and associating them with failing tests in the results.

I also wanted to make sure I understood the reason that there isn't a "ServiceWorkerProcess" binary on disk, nor will there be a crash log containing the name "ServiceWorkerProcess".  And now I do.

[youenn fablet]

*** Bug 206523 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 206275 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 206594 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 206595 has been marked as a duplicate of this bug. ***

[Jason Lawrence]

*** Bug 206935 has been marked as a duplicate of this bug. ***

[youenn fablet]

*** This bug has been marked as a duplicate of bug 206994 ***