The delete_cookie.py WPT test opens tab-modal dialogues for testing WebDriver behaviour. Because geckodriver/Marionette does not implement some of this behaviour yet, the tests clean up state by quitting Firefox. To do this they send a command to geckodriver, which calls the Marionette:Quit command in Gecko [1]. This internally evaluates to this: > Services.startup.quit(Ci.nsIAppStartup.eForceQuit); I’m not sure this is specifically related to the tab-modal dialogue being open or not, but it is a fairly frequent intermittent and easily reproducible on Linux 64-bit with the following command: > MOZ_HEADLESS=1 ./mach wpt --webdriver-arg=-vv testing/web-platform/tests/webdriver/tests/cookies/delete_cookie.py --timeout-multiplier 100 [1] https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/testing/marionette/driver.js#3268

I assume you are talking about the slow shutdown as you observed? That is not that clear from the comment 0. If yes see also bug 1425559 which was similar but for two tabmodals. It all could be related to slow shutdowns due to bug 1435343.

Yes, so this causes the Firefox process to never terminate. It is however only reproducible in headless mode. I’m only assuming it’s a race condition related to modal dialogues.

As already mentioned on IRC best here is to copy both the .dmp and .extra file into the `~/.firefox/Crash Reports/pending` (or similar folder), and submit it via `about:crashes`. Then we can see if it is an already known shutdown hang.

(In reply to Henrik Skupin (:whimboo) from comment #4) > As already mentioned on IRC best here is to copy both the .dmp > and .extra file into the `~/.firefox/Crash Reports/pending` (or > similar folder), and submit it via `about:crashes`. Then we can > see if it is an already known shutdown hang. Thanks! For posterity, the location is ~/Library/Application\ Support/Firefox/Crash Reports/pending on macOS.

Crash report is https://crash-stats.mozilla.com/report/index/44113b15-acf1-44a6-8dee-fca0d0180307.

(In reply to Andreas Tolfsen ‹:ato› from comment #6) > Crash report is > https://crash-stats.mozilla.com/report/index/44113b15-acf1-44a6-8dee- > fca0d0180307. So this is a self-built Firefox? I assume so because no symbols are available for it. To actually analyze it you would need the minidump_stackwalk binary and the symbols as downloaded from TaskCluster. I'm happy to guide you. Otherwise try to reproduce with a Nightly build, which has public symbols by default.

(In reply to Andreas Tolfsen ‹:ato› from comment #5) > For posterity, the location is ~/Library/Application\ > Support/Firefox/Crash Reports/pending on macOS. This minidump is from Linux, so you need Linux to actually analyze it as mentioned in my last comment.

Here some commands which help given that I cannot reproduce it on MacOS and I don't have a Linux system setup for wdspec tests yet due to local artifact builds. To get the minidump file run: > testing/mozharness/external_tools/tooltool.py fetch -m testing/config/tooltool-manifests/linux64/releng.manifest > chmod u+x linux64-minidump_stackwalk Build symbols: > mach buildsymbols > unzip obj/*/dist/*symbols.zip -D symbol_path Run minidump_stackwalk: > linux64-minidump_stackwalk -m minidump_file -s symbol_path That should give you the crash details. Otherwise try to run via gdb or set the debugger options for wp-tests.

I wonder if setting the following pref will give us more details for hangs during shutdown: https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#1078-1079 // Extra logging for AsyncShutdown barriers and phases pref("toolkit.asyncshutdown.log", false); Andreas, could you try that. Maybe it is easier to find out the culprit here.