1912957 - Crash in [@ shutdownhang | ntdll.dll | kernelbase.dll | mozilla::SpinEventLoopUntil | nsThreadPool::ShutdownWithTimeout]

Status: NEW

(Core :: XPCOM, defect)

Description

[Bogdan Maris, Desktop Test Engineering]

Crash report: https://crash-stats.mozilla.org/report/index/7918b6b6-1d36-4ca6-85ee-7c4fb0240813

MOZ_CRASH Reason: Shutdown hanging at step XPCOMShutdownThreads. Something is blocking the main-thread.

Top 9 frames:

0  xul.dll  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:317
0  xul.dll  mozilla::(anonymous namespace)::RunWatchdog(void*)  toolkit/components/terminator/nsTerminator.cpp:244
1  nss3.dll  _PR_NativeRunThread(void*)  nsprpub/pr/src/threads/combined/pruthr.c:399
2  nss3.dll  pr_root(void*)  nsprpub/pr/src/md/windows/w95thred.c:139
3  ucrtbase.dll  thread_start<unsigned int (__cdecl*)(void*), 1>
4  kernel32.dll  kernel32.dll@0x1230c
5  mozglue.dll  mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mo...  toolkit/xre/dllservices/mozglue/nsWindowsDllInterceptor.h:150
5  mozglue.dll  patched_BaseThreadInitThunk(int, void*, void*)  toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:562
6  ntdll.dll  ntdll.dll@0x75b28

Affected versions

• Nightly 131.0a1
• Nightly 128.0a1

Tested platforms

• Affected platforms: Windows 11 ARM
• Unaffected platforms: macOS 13 and Ubuntu 22.04

Preconditions

• Have "devtools.chrome.enabled" set to "true"

Steps to reproduce

1. Open the Browser Console
2. Paste the following

await Cc[
  "@mozilla.org/browser/shell-service;1"
].getService(Ci.nsIWindowsShellService).pinCurrentAppToTaskbarAsync(true);

3. Without interracting with the notification exit Firefox or restart it by using CTLR+ALT+R within the Browser Console

Expected result

• Not sure if we should dismiss the notification or not but the Browser is closed or restarted (depending on step 3 from above).

Actual result

• The browser process remains active and a crash happens in a few seconds.

Regression range

• A bit hard to check for regression for this one since it must be made manually but I also had. If need be I can check for one.

Additional notes

• On Windows 10 and Windows 11 (Non ARM) we get a slightly different crash signature @ shutdownhang | mozilla::SpinEventLoopUntil | nsThreadPool::ShutdownWithTimeout that points to bug 1866944. Not sure if this should also be considered a duplicate of that bug but if so feel free to mark it so.

Comment 1

[Nipun Shukla]

Currently we do block the main thread while pinning, so this isn't exactly unexpected and should happen regardless of whether we pin privately or normally. This has probably been present since Fx127 with this patch being the cause. Nicholas, do you think your MozPromise work in bug 1893458 might help with fixing this?

Comment 2

[Nick Rishel [:nrishel]]

Right, this should be fixed by moving to MozPromise. I'm kind of surprised this wasn't been a problem before?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit BugBot documentation.