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>
<rdar://problem/58670130>
External test results where this occurred: <https://build.webkit.org/results/Apple%20iOS%2013%20Simulator%20Debug%20WK2%20(Tests)/r254469%20(1683)/results.html>
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.
> 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.
(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.
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.
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?
(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).
> 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.
(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.
*** Bug 206523 has been marked as a duplicate of this bug. ***
*** Bug 206275 has been marked as a duplicate of this bug. ***
*** Bug 206594 has been marked as a duplicate of this bug. ***
*** Bug 206595 has been marked as a duplicate of this bug. ***
*** Bug 206935 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 206994 ***