1843744 - Crash in [@ mozilla::dom::workerinternals::RuntimeService::CrashIfHanging] shutting down Thunderbird (exit/quit)

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect, P3)

Description

[Wayne Mery (:wsmwk)]

#3 crash for 102.13.0
#7 crash for 115.0
Most user comments cite quitting thunderbird

Crash report: https://crash-stats.mozilla.org/report/index/13f699b7-d08a-4c62-8425-78bfd0230713

MOZ_CRASH Reason: Workers Hanging - 1|A:5|S:0|Q:0-BC:1IsChromeWorker(false)|WorkerDebuggeeRunnable::mSender|WorkerDebuggeeRunnable::mSender-BC:1IsChromeWorker(false)|WorkerDebuggeeRunnable::mSender|WorkerDebuggeeRunnable::mSender-BC:1IsChromeWorker(false)|WorkerDebuggeeRunnable::mSender|WorkerDebuggeeRunnable::mSender-BC:1IsChromeWorker(false)|WorkerDebuggeeRunnable::mSender|WorkerDebuggeeRunnable::mSender-BC:1IsChromeWorker(false)|WorkerDebuggeeRunnable::mSender|WorkerDebuggeeRunnable::mSender

Top 8 frames of crashing thread:

0  xul.dll  mozilla::dom::workerinternals::RuntimeService::CrashIfHanging  dom/workers/RuntimeService.cpp:1603
1  xul.dll  mozilla::`anonymous namespace'::RunWatchdog  toolkit/components/terminator/nsTerminator.cpp:232
2  nss3.dll  PR_NativeRunThread  nsprpub/pr/src/threads/combined/pruthr.c:399
3  nss3.dll  pr_root  nsprpub/pr/src/md/windows/w95thred.c:139
4  ucrtbase.dll  thread_start<unsigned int , 1>  
5  kernel32.dll  BaseThreadInitThunk  
6  mozglue.dll  patched_BaseThreadInitThunk  toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:572
7  ntdll.dll  RtlUserThreadStart  

Other examples
bp-29ff4f9a-a593-44c6-b089-661bc0230710
bp-66d3933b-718d-4b48-a5e1-341b60230421
bp-3b422303-a976-43dd-a595-b2b6c0230524

Comment 1

[Magnus Melin [:mkmelin]]

Seem not a lot to go on.

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #1)

Seem not a lot to go on.

Lots of information in bug 1435343.
I don't think it will, but perhaps bug 1793437 might factor in for 115

Comment 3

[Wayne Mery (:wsmwk)]

I crashed on Mac with one pop account set to "empty trash on exit" bp-fb2bc3c5-300d-4ee1-bc87-b5ebc0230718

I don't think it will, but perhaps bug 1793437 might factor in for 115

Or maybe it will. That is now duped to Bug 1788599 - Thunderbird 105.0b1 15 second shutdown due BlockShutdown, when working online waiting on nsMsgAccountManager::CleanupOnExit.

Comment 4

[Wayne Mery (:wsmwk)]

Insufficient crash rate on nightly to determine whether bug 1788599 had an impact after landing two days ago.
Will need to check beta and release crash numbers in a couple days.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #4)

Insufficient crash rate on nightly to determine whether bug 1788599 had an impact after landing two days ago.
Will need to check beta and release crash numbers in a couple days.

No change in

• beta crash rate
• release crash rate

Comment 6

[Wayne Mery (:wsmwk)]

Also, from bug 1435343...

1: It's likely that the bug 1800659 fixes will be a massive improvement for these specific hangs and would be appropriate for uplift on its own, but it also:

    Represents a major shift in worker behavior that potentially will result in a number of fixes in other components and this would increase uplift risk because those fixes may result in their own cascade of fixes which could intertwine with new functionality, etc.
    Is expected to be followed-up by a number of other worker technical debt paydown refactorings for which it's also not clear we could uplift. And arguably it would be better to leave ESR in the pre-bug 1800659 state that has been the equilibrium state for a long time rather than having ESR have a temporary intermediate equilibrium that might only exist in Fx116 or maybe not exist in any shipped Firefox if we land more refactorings in 116 that we definitely don't want to risk uplifting (I have a few of these...).

Thanks for that info. So indeed bug 1800659 is on version 116 and not back ported to esr115

Comment 7

[Wayne Mery (:wsmwk)]

bp-1b54fa0e-c9d1-495f-b311-c76ea0231213 on Mac running beta 121. Had addons FileLink Provider for Dropbox and Quick Folder Key Navigation.
with security.prompt_for_master_password_on_startup = false (which for Thunderbird is not the default)

Comment 8

[Wayne Mery (:wsmwk)]

Some of the Mac users report crash being password related.

Comment 9

[Worcester12345]

(In reply to Wayne Mery (:wsmwk) from comment #6)

Also, from bug 1435343...

1: It's likely that the bug 1800659 fixes will be a massive improvement for these specific hangs and would be appropriate for uplift on its own, but it also:

    Represents a major shift in worker behavior that potentially will result in a number of fixes in other components and this would increase uplift risk because those fixes may result in their own cascade of fixes which could intertwine with new functionality, etc.
    Is expected to be followed-up by a number of other worker technical debt paydown refactorings for which it's also not clear we could uplift. And arguably it would be better to leave ESR in the pre-bug 1800659 state that has been the equilibrium state for a long time rather than having ESR have a temporary intermediate equilibrium that might only exist in Fx116 or maybe not exist in any shipped Firefox if we land more refactorings in 116 that we definitely don't want to risk uplifting (I have a few of these...).

Thanks for that info. So indeed bug 1800659 is on version 116 and not back ported to esr115

Since this seems so huge, would it make sense to do a special branch just for this change, and everything that comes with it?

Comment 10

[Intermittent Failures Robot]

1 failures in 4116 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-beta: 1

Platform and build breakdown:

• linux1804-64-devedition-qr: 1
  • opt: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1843744&startday=2024-06-24&endday=2024-06-30&tree=all

Comment 11

[Wayne Mery (:wsmwk)]

This crash signature is totally gone in version 128. And as best I can tell

• based on timing, neither bug 1788599 nor bug 1882214 will have had a significant impact in reducing the crashes
• based on items on user comments (email addresses), I find no connection to any current 128 crashes (but it's also true that within this crash signature, I see very few users with repeat reports)

Crash report: https://crash-stats.mozilla.org/report/index/266584dd-7719-4668-bf07-2833b0240905

MOZ_CRASH Reason: Workers Hanging - 1|A:1|S:0|Q:0-BC:1IsChromeWorker(false)|WorkerDebuggeeRunnable::mSender|WorkerDebuggeeRunnable::mSender

Top 10 frames:

0  xul.dll  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:264
0  xul.dll  mozilla::dom::workerinternals::RuntimeService::CrashIfHanging()  dom/workers/RuntimeService.cpp:1610
1  xul.dll  mozilla::(anonymous namespace)::RunWatchdog(void*)  toolkit/components/terminator/nsTerminator.cpp:232
2  nss3.dll  _PR_NativeRunThread(void*)  nsprpub/pr/src/threads/combined/pruthr.c:399
3  nss3.dll  pr_root(void*)  nsprpub/pr/src/md/windows/w95thred.c:139
4  ucrtbase.dll  thread_start<unsigned int (__stdcall*)(void*), 1>
5  kernel32.dll  BaseThreadInitThunk
6  mozglue.dll  mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mo...  toolkit/xre/dllservices/mozglue/nsWindowsDllInterceptor.h:150
6  mozglue.dll  patched_BaseThreadInitThunk(int, void*, void*)  toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:617
7  ntdll.dll  __RtlUserThreadStart

Comment 12

[Magnus Melin [:mkmelin]]

-> WFM then