TB 60.5.0 ESR:
https://hg.mozilla.org/releases/comm-esr60/rev/e020af22505797737aa90db66b9d983f8a5f0fa5

It's a bit early to fully guage the state of 65.0b2 [1] but early results suggest this patch hasn't helped at all - the crash rate hasn't changed in either absolute numbers nor relative to other crash signatures - still ~30% of crashes. So more investigation is needed, and I think it is premature to uplift even a correctness patch to ESR - in part because the crash signature doesn't even exist in 60.4.0.

[1] the closest approximation to total crash count I can provide is

• 65.0b2 20190107162308 last 3 days ~530 crashes - https://crash-stats.mozilla.com/search/?build_id=20190107162308&product=Thunderbird&date=%3E%3D2019-01-07T12%3A35%3A30.000Z&date=%3C2019-01-14T12%3A35%3A30.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
• 65.0b1 20181222205702 last 4 days ~560 crashes - https://crash-stats.mozilla.com/search/?build_id=20181222205702&product=Thunderbird&date=%3E%3D2019-01-10T17%3A35%3A00.000Z&date=%3C2019-01-14T17%3A35%3A30.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Multiple examples of recent nightly crashes, for example bp-49ac9ce4-3c61-4e3d-a159-f5bdc0190122

Graph of beta https://crash-stats.mozilla.com/signature/?product=Thunderbird&release_channel=beta&signature=nsXPCWrappedJS%3A%3ARelease&date=%3E%3D2018-10-24T10%3A28%3A28.000Z&date=%3C2019-01-24T09%3A28%3A28.000Z#graphs

65.0b3 just shipped yesterday, so can't judge if it has the same crash rate. But no reason to expect it won't.

statistically, patch definitely had no impact.

earliest crash for NS_CycleCollectorSuspect3 is buildid 20181111101548 65.0a1 bp-9cd3900b-1992-425b-b9a8-293960181112
(drum roll)
earliest crash for nsXPCWrappedJS::Release is buildid 20181110100128 65.0a1 bp-891ace88-c31e-410f-bae4-5fd580181218

Does any patch landing in early November time frame stand out as possible regressor?

I think you're mixing up two issues here. The original crash in nsSmtpUrl::~nsSmtpUrl() and a crash coming from RDF:
comm/rdf/base/nsCompositeDataSource.cpp:515 - bp-9cd3900b-1992-425b-b9a8-293960181112

The latter will go when we eliminate RDF. No idea what caused the former. OK, the patch was a shot in the dark like so often, but it also didn't hurt and added some correctness.

FYI I have just encountered this crash in TB 66.0b3
bp-f43d1f2d-0bee-437a-a26b-1ea980190325

(In reply to Richard Leger from comment #13)

FYI I have just encountered this crash in TB 66.0b3
bp-f43d1f2d-0bee-437a-a26b-1ea980190325

Crashed occurred following those steps:

1. Forward an email (with embedded pictures)
2. Enter email address or recipient
3. Click Send button
4. Email send windows closed automatically
5. Close a TB opened Tab (msg tab more likely) by pressing the cross close icon on the tab
   ==> TB crashed

After re-opening TB the sent message appeared correctly in sent items, and the tab I was trying to close may still be opened but I am not sure if it was the same tab or not... looks like it...

I tried that and it didn't crash, neither in TB 60 nor the forthcoming TB 67 beta.

I just hit this bug for a second time in a week:
1st crash: https://crash-stats.mozilla.com/report/index/f6a47ae4-f37a-4e64-9b1b-c756e0190627
2nd crash: https://crash-stats.mozilla.com/report/index/c3031b1a-7677-4064-923c-dae5a0190705

(In reply to Arthur K. from comment #16)

I just hit this bug for a second time in a week:
1st crash: https://crash-stats.mozilla.com/report/index/f6a47ae4-f37a-4e64-9b1b-c756e0190627
2nd crash: https://crash-stats.mozilla.com/report/index/c3031b1a-7677-4064-923c-dae5a0190705

These are via nsMsgCompFields.cpp

0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp:256 context
1 xul.dll nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
2 xul.dll void nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
3 xul.dll nsMsgCompFields::Release() comm/mailnews/compose/src/nsMsgCompFields.cpp:62 cfi
4 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 cfi
5 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
6 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
7 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi

(In reply to Jorg K (GMT+2) from comment #12)

I think you're mixing up two issues here. The original crash in nsSmtpUrl::~nsSmtpUrl() and a crash coming from RDF:
comm/rdf/base/nsCompositeDataSource.cpp:515 - bp-9cd3900b-1992-425b-b9a8-293960181112

It's true, I didn't examine the stacks. I haven't done a thorough analysis, but I think the majority of crashes are not via RDF, but examples like comment 17.

bp-4366ca49-3a88-4110-b58a-f50180190708 is an example via nsSmtpUrl.cpp Anything that can be done there?

0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp:256 context
1 xul.dll static unsigned long ReleaseThunk(struct IUnknown*) xpcom/reflect/xptcall/xptcall.cpp:28 cfi
2 xul.dll nsSmtpUrl::~nsSmtpUrl() comm/mailnews/compose/src/nsSmtpUrl.cpp:578 cfi
3 xul.dll [thunk]:nsSmtpUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
4 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
5 xul.dll [thunk]:nsImapUrl::Release`adjustor{8}' () cfi
6 xul.dll nsMsgProtocol::~nsMsgProtocol() comm/mailnews/base/util/nsMsgProtocol.cpp:87 frame_pointer
7 xul.dll void nsSmtpProtocol::~nsSmtpProtocol() comm/mailnews/compose/src/nsSmtpProtocol.cpp:222 cfi
8 xul.dll nsDSURIContentListener::Release() comm/mailnews/base/util/nsMsgProtocol.cpp:50 cfi

The latter will go when we eliminate RDF. No idea what caused the former. OK, the patch was a shot in the dark like so often, but it also didn't hurt and added some correctness.

If there are multiple causes here then perhaps we need to break this up. Plus we should have crash-stats give us a better crash siganture.

bp-a977842f-6512-41b1-b59b-d80d10190708 another RDF example?
0 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp:3761 context
1 xul.dll CompositeDataSourceImpl::Release() comm/rdf/base/nsCompositeDataSource.cpp:515 cfi
2 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7507 cfi
3 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7497 cfi
4 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7509 cfi
5 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:75 cfi
6 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi

bp-361663a6-435a-40f2-b9f1-ff1a10190708 via compose
0 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp:3761 context
1 xul.dll IdleRequestExecutor::Release() js/xpconnect/loader/ChromeScriptLoader.cpp:362 cfi
2 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 cfi
3 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
4 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
5 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi
6 xul.dll ArrayBufferInputStream::Release() comm/mailnews/addrbook/src/nsAbBooleanExpression.cpp:9 cfi
7 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7507 cfi
8 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7497 cfi

This will be very hard to find and fix, since some internal memory magic has gone wrong. The stacks all show a cascade of destructors, see below. The first destructor that runs is the IMAP protocol descructor, nsImapProtocol::~nsImapProtocol(), and that of course goes to destroy a lot of dependent data, be it URL data, compose field data, or other stuff like RDF. So somehow somewhere something goes wrong with memory de-allocation.

Looking at the various reports, we see two classes:
MOZ_RELEASE_ASSERT(NS_IsMainThread()) (nsXPCWrappedJS::Release called off main thread)
So something got release on the wrong thread, likely the IMAP thread.

The other one is:
EXCEPTION_ACCESS_VIOLATION_READ
That's a straight crash.

So if you want to split the bug, that's how you need to split it. The MOZ_RELEASE_ASSERT() crash should be fixable with a reproducible example.

https://crash-stats.mozilla.com/report/index/f6a47ae4-f37a-4e64-9b1b-c756e0190627 from comment #16: MOZ_RELEASE_ASSERT()

0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp:256 context
1 xul.dll nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
2 xul.dll void nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
3 xul.dll nsMsgCompFields::Release() comm/mailnews/compose/src/nsMsgCompFields.cpp:62 cfi
4 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 cfi
5 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
6 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
7 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi
8 xul.dll ArrayBufferInputStream::Release() comm/mailnews/addrbook/src/nsAbBooleanExpression.cpp:9 cfi
9 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7507 cfi
10 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7497 cfi
11 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7509 cfi
12 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:75 cfi
13 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
14 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 cfi
15 xul.dll nsImapProtocol::~nsImapProtocol() comm/mailnews/imap/src/nsImapProtocol.cpp:662

and

EXCEPTION_ACCESS_VIOLATION_READ

0 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp:3761 context
1 xul.dll IdleRequestExecutor::Release() js/xpconnect/loader/ChromeScriptLoader.cpp:362 cfi
2 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 cfi
3 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
4 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
5 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi
6 xul.dll ArrayBufferInputStream::Release() comm/mailnews/addrbook/src/nsAbBooleanExpression.cpp:9 cfi
7 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7507 cfi
8 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7497 cfi
9 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7509 cfi
10 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:75 cfi
11 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
12 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
13 xul.dll nsImapUrl::Release() comm/mailnews/compose/src/nsSmtpUrl.cpp:583 cfi
14 xul.dll nsImapProtocol::~nsImapProtocol()
13 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
14 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 cfi
15 xul.dll nsImapProtocol::~nsImapProtocol() comm/mailnews/imap/src/nsImapProtocol.cpp:662

From comment #18: - MOZ_RELEASE_ASSERT(NS_IsMainThread())

0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp:256 context
1 xul.dll static unsigned long ReleaseThunk(struct IUnknown*) xpcom/reflect/xptcall/xptcall.cpp:28 cfi
2 xul.dll nsSmtpUrl::~nsSmtpUrl() comm/mailnews/compose/src/nsSmtpUrl.cpp:578 cfi
3 xul.dll [thunk]:nsSmtpUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
4 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
5 xul.dll [thunk]:nsImapUrl::Releaseadjustor{8}' () cfi 6 xul.dll nsMsgProtocol::~nsMsgProtocol() comm/mailnews/base/util/nsMsgProtocol.cpp:87 frame_pointer 7 xul.dll void nsSmtpProtocol::~nsSmtpProtocol() comm/mailnews/compose/src/nsSmtpProtocol.cpp:222 cfi 8 xul.dll nsDSURIContentListener::Release() comm/mailnews/base/util/nsMsgProtocol.cpp:50 cfi 9 xul.dll [thunk]:nsImapProtocol::Releaseadjustor{28}' () cfi
10 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 frame_pointer
11 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
12 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
13 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi
14 xul.dll ArrayBufferInputStream::Release() comm/mailnews/addrbook/src/nsAbBooleanExpression.cpp:9 cfi
15 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7507 cfi
16 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7497 cfi
17 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7509 cfi
18 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:75 cfi
19 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
20 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
21 xul.dll nsImapUrl::Release() comm/mailnews/compose/src/nsSmtpUrl.cpp:583 cfi
22 xul.dll nsImapProtocol::~nsImapProtocol()

From comment #19:

EXCEPTION_ACCESS_VIOLATION_READ

0 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp:3761 context
1 xul.dll CompositeDataSourceImpl::Release() comm/rdf/base/nsCompositeDataSource.cpp:515 cfi
2 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7507 cfi
3 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7497 cfi
4 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7509 cfi
5 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:75 cfi
6 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
7 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
8 xul.dll nsImapUrl::Release() comm/mailnews/compose/src/nsSmtpUrl.cpp:583 cfi
9 xul.dll nsImapProtocol::~nsImapProtocol() comm/mailnews/imap/src/nsImapProtocol.cpp:662

Gene, could you please poke around this a bit, it's clearly an IMAP issue.

Maybe we need to sprinkle in some NS_ReleaseOnMainThreadSystemGroup() calls like we already have in other places:
https://searchfox.org/comm-central/search?q=releaseonmain&case=false&regexp=false&path=mailnews%2F

(In reply to Jorg K (GMT+2) from comment #22)

Maybe we need to sprinkle in some NS_ReleaseOnMainThreadSystemGroup() calls like we already have in other places:
https://searchfox.org/comm-central/search?q=releaseonmain&case=false&regexp=false&path=mailnews%2F

You're talking about comment 20, class 1 MOZ_RELEASE_ASSERT? Isn't this then what bug 1175168 is about, where Ben has caught the scent? We fixed a series of main thread issues in Bug 1133892, bug 1324893 and bug 1299920.

(To recap regarding reporters, we have Richard and Arthur.)

Correct, Wayne, I suggested to fix "class 1" from a intended crash via MOZ_RELEASE_ASSERT() since something isn't release on the main tread by sprinkling in those calls. That's exactly what bug 1175168 is about, thanks for piecing it all together. I suggest to move that bug forward to see what happens to the remaining "class 2" crashes EXCEPTION_ACCESS_VIOLATION_READ.

NS_ReleaseOnMainThreadSystemGroup() sprinkles don't get us all the way there. There are a few operations which need to be split out into their own nsIRunnable block, I think.

For example, the patch that was applied to fix bug 1133892 does indeed offload all the Release() calls to the main thread, but when it comes to releasing the objects referenced in the mUrlListeners collection, it inadvertently triggers another not-on-the-main-thread-ASSERT as it iterates over them. As in crash 1347677c-3bca-40aa-9922-979230190709.

I'm happy to pick my way through these and come up with patches (I'm still trying to get it all straight in my head, but I think I'm almost there).
We're making certain objects "threadsafe-for-jswrapper" as we hit problems, but I'm thinking it's also worth stepping back and taking a look at the bigger picture...

(In reply to Ben Campbell from comment #25)

...
We're making certain objects "threadsafe-for-jswrapper" as we hit problems, but I'm thinking it's also worth stepping back and taking a look at the bigger picture...

This area has been problematic for such a long time, that taking time to consider the Big Picture would be a good thing.

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

This area has been problematic for such a long time, that taking time to consider the Big Picture would be a good thing.

Of course, no reason we can't slap on some small-picture patches to stop it crashing in the meantime ;-)

One bigger-picture thought from digging through protocols code this week:
It seems like the various TB-specific URL classes all add the concept of request state and listeners on top of the core URI functionality (see nsIMsgMailNewsUrl).
(I haven't done the archeology required to know for sure, but I suspect it's a result of keeping things working after some big M-C network refactors).
In any case it seems like it'd be nice to get the TB Url classes back to just being Urls (glorified strings, essentially, with extra functions to handle protocol-specific url manipulations). It'd certainly avoid some of these thread-related issues.
This probably goes hand-in-hand with how TB handles it's nsIChannel/nsiRequest-based classes. I think there's a lot of scope for simplifying the way they are constructed and managed (lots of protocol-specific functions which bypass the usual channel creation mechanisms).

There have been a few refactors touching imap in the last decade, notably:

• (TB10) Bug 675407 - Remove XPCOM proxies from comm-central
• (TB49) Bug 1270631 - Port bug 1268313 part 7 to c-c [Move NS_NewRunnableMethod to mozilla::NewRunnableMethod]
• (TB17) and for good measure (not imap specific) Bug 779130 - Fix nsresult abuses in comm-central and Bug 413590 - Remaining null-arg checks in TB

Perhaps I have missed one or two, but these are all the ones I remember or was able to find via search.

More forensics, to add to comment 29

• (TB36) Bug 1088497 - Implement NewChannel2 in mailnews
• (TB54) Bug 791645 - Rewrite calls to synchronous nsIProtocolProxyService::DeprecatedBlockingResolve with Async code as DeprecatedBlockingResolve disappeared with bug 436344

And a couple esoteric items which were not really refactorings

• (TB16) Bug 740453 - Thunderbird downloads the entire message for each part in a multipart message
• (TB16) Bug 92111 - IMAP: Attachments not fully downloaded (due to incorrect/smaller RFC822.SIZE by MS Exchange, gmail, and possibly others)

Makes one wonder what other exchange-related things may be behaving badly.

We're now at 2,000 crashes per day! That is extreme for only half of users are on 68.*, i.e. we can expect the count to double.

How about some interim patch, while the larger refactoring of comment 28 happens in another bug report?

Half? Looks more like 20% according to https://stats.thunderbird.net/#version adding 68.2.2 and 68.3.

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #32)

Half? Looks more like 20% according to https://stats.thunderbird.net/#version adding 68.2.2 and 68.3.

Indeed you are correct. And we're now at 41% for 68.x, quickly approaching 50%

we're currently seeing 30,000 crashes per week between this and bug 1175168 - so about 5,000 per day on a weekday

The action seems to be in bug 1586494 so let's concentrate there

FYI, got a crash again in 74.0b2 (32-bit)...
bp-0dc515a3-75af-4a2e-bce3-6e4a90200312
I was not even using the app when it happened... just crashed by itself in the background...

May be this crash can be forced by saving a draft into a nearly full (or overquota) IMAP folder.
Small mails were okay, but a mail with "corona homeschooling homework" jpg attachements crashed.
(Yes, I know SMTP is not a file transfer protocol.)

FYI on Windows 10 (64 bit) home:

bp-d76721a2-d93a-4116-99ef-1eb950200508

Thunderbird 68.8.0 Crash Report [@ nsXPCWrappedJS::Release ]
Crashing Thread (53)
Frame Module Signature Source Trust
0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp:256 context
1 xul.dll static unsigned long ReleaseThunk(struct IUnknown*) xpcom/reflect/xptcall/xptcall.cpp:28 cfi
2 xul.dll nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
3 xul.dll void nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
4 xul.dll nsMsgCompFields::Release() comm/mailnews/compose/src/nsMsgCompFields.cpp:62 cfi
5 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 cfi
6 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
7 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
8 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi
9 xul.dll ArrayBufferInputStream::Release() comm/mailnews/addrbook/src/nsAbBooleanExpression.cpp:9 cfi
10 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7506 cfi
11 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7496 cfi
12 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7508 cfi
13 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:76 cfi
14 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
15 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
16 xul.dll nsImapUrl::Release() comm/mailnews/compose/src/nsSmtpUrl.cpp:583 cfi
17 xul.dll nsImapProtocol::~nsImapProtocol() comm/mailnews/imap/src/nsImapProtocol.cpp:662 cfi
18 xul.dll [thunk]:nsImapProtocol::vector deleting destructor'adjustor{24}' (unsigned int) cfi
19 xul.dll nsDSURIContentListener::Release() comm/mailnews/base/util/nsMsgProtocol.cpp:50 frame_pointer
20 xul.dll [thunk]:nsImapProtocol::Release`adjustor{4}' () cfi
21 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1222 frame_pointer
22 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:486 cfi
23 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:303 cfi
24 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:308 cfi
25 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:290 cfi
26 xul.dll nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:454 cfi
27 nss3.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 cfi
28 nss3.dll static unsigned int pr_root(void*) nsprpub/pr/src/md/windows/w95thred.c:137 cfi
29 ucrtbase.dll thread_start<unsigned int (__stdcall*)(void*), 1> cfi
30 kernel32.dll BaseThreadInitThunk cfi
31 mozglue.dll static void patched_BaseThreadInitThunk(int, void*, void*) mozglue/build/WindowsDllBlocklist.cpp:625 cfi
32 ntdll.dll _RtlUserThreadStart cfi
33 ntdll.dll _RtlUserThreadStart cfi

(In reply to Robert Hartmann from comment #36)

May be this crash can be forced by saving a draft into a nearly full (or overquota) IMAP folder.
Small mails were okay, but a mail with "corona homeschooling homework" jpg attachements crashed.
(Yes, I know SMTP is not a file transfer protocol.)

FYI on Windows 10 (64 bit) home:

Can you attach or provide the offending email with jpg file? If not, can you tell us how big it is? Also, what are the quota statistics for the almost full folder? Do you know the imap server type? This might help in duplicating the problem. Also, are you storing the Sent folder emails locally for "offline use" or do you just store the headers? (For stored for offline use is the default.)
Did you see any errors regarding the exceeded quota limit before the crash? Can you often duplicate the crash after sending the large email? Any other details you provide might also be helpful. Thanks for the report!

(In reply to gene smith from comment #37)

(In reply to Robert Hartmann from comment #36)

May be this crash can be forced by saving a draft into a nearly full (or overquota) IMAP folder.
Small mails were okay, but a mail with "corona homeschooling homework" jpg attachements crashed.
(Yes, I know SMTP is not a file transfer protocol.)

FYI on Windows 10 (64 bit) home:

Can you attach or provide the offending email with jpg file? If not, can you tell us how big it is?

no, to the first part. Yes, to the second part:
IMG_0501.jpg (661KB)
IMG_0502.jpg (732KB)
IMG_0503.jpg (807KB)
IMG_0503.jpg (647KB)

Also, what are the quota statistics for the almost full folder?

Sadly Thunderbird didn't recieve any quota statistics from GMX.

TB 68.8.0 (32-Bit) say "Information zum Speicherplatzkontingent sind nicht verfügbar, da der Ordner nicht geöffnet ist."
that is german for "Information about quota is not available, because folder is not open"
(May be the german text is a wrong translated message, because I have opened the folder "Entwürfe" = drafts)
I tried to attach a screenshot from TB message window to here, but I am not able to do it.

TB 78.0a1 (2020-05-08) (64-bit) say "This server does not support quotas"

Do you know the imap server type?

IMAP (SSL/TLS)

This might help in duplicating the problem.
Also, are you storing the Sent folder emails locally for "offline use" or do you just store the headers? (For stored for offline use is the default.)

yes store for offline reading.

Did you see any errors regarding the exceeded quota limit before the crash?
If you want to know, if TB gives me a message like "quota problems", than no.
But GMX sended me a statisticless warning mail and on their Webpage I can see (1,0 GB used from 1,0 GB used).

Can you often duplicate the crash after sending the large email?
Any other details you provide might also be helpful. Thanks for the report!

Befor the crash I see the message, that a draft could not be store and the question if I want to retry.
I choose multiple times retry and than abort.
But I can't remember if the crash happens before "abort" or if it comes after.
(I tried to send the mail twice, at the second time I am sure that I had choosen "abort" ;
and the mail at second time was sended because I receive a answer but TB crashed with an other problem bp-34432a1c-ead1-4ca1-8b8b-3d83f0200508 too: )
May be the draft at first time would be crypted by Enigmail and therefor it could be bigger than the uncrypted but sended mail ...

Oh, by the way, I took the *jpg from a former mail to my new one and rename them inside Thunderbird.
While thinking about good names the draft auto save starts , failed and than crashed.

Best regards.

Thanks for the info. Do you have another account that is not at its quota limit? If so, can you save the draft with the large attachments to that account without a crash?

If you can duplicate the crash fairly easily, maybe an IMAP:5 log would show something. If you could record and attach the log it might help: https://wiki.mozilla.org/MailNews:Logging

no, to the first part. Yes, to the second part:
IMG_0501.jpg (661KB)
IMG_0502.jpg (732KB)
IMG_0503.jpg (807KB)
IMG_0503.jpg (647KB)

I assume this means the offending email had 4 attachments of the size you show?

IMAP (SSL/TLS)

I was asking about the imap server type used by GMX, e.g., dovecot, courier, home-brewed etc. Anyhow, if you provide a log it might contain this info.

The quota handling in tb has been improved in tb daily. However to see it you still have to have the folder open (clicked-on) and the server has to support quota reporting. Some do, some don't. If you free-up some space on the account (which sounds like it is at the 1G limit) does the crashing of tb stop?

Okay ... I found a way with German language setting to reproduce that crash maybe without having interaction with any server!

TB show me the IMAP folder structure for GMX:
Posteingang
Entwürfe
Vorlagen
Gesendet
Archiv
Junk
Spamverdacht
Gelöscht
Outbox

extract from log file just focus on that mail folder "Entwürfe":
I/IMAP 1433D000:imap.gmx.net:NA:ProcessCurrentURL:imap://Robert_Hartmann%40gmx%2Enet@imap.gmx.net:993/select%3E/Entw%26APw-rfe:

1. Make sure that there is no folder for drafts in "Mail\Local Folders"

2. remove network connection (deactivate WLAN or remove wire)

3. Write a mail and try to save as draft to GMX-Account
   because IMAP server is not available - wait a while , ie make screenshot and save it some where -
   and than choose "save to local folder".
   => and TB crashed; stack trace below

4. After restart TB you can see a new local mail folder "Entwürfe" containing the stored Mail.
   But that mail couldn't be opened for reading.
   In the Message viewing plane there is written a link "Oder Sie können eine Ausnahme hinzufügen…"
   pointing to javascript:showSecuritySection()
   Nothing happens if I click on that link.

5. Rename Folder "Entwürfe" to something else and the saved mail could be read.

This crash can be reproduced only if you have no local draft folder at first.
The reading problem with mails inside "Entwürfe" does not create a crash.

I can do the same test with TB beta and TB daily ... a bit later...

Name Thunderbird (32bit)
Version 68.8.1
Build-ID 20200521175255
bp-bb3c18a4-bc7f-4158-8183-5ad540200524

0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp:256 context
1 xul.dll static unsigned long ReleaseThunk(struct IUnknown*) xpcom/reflect/xptcall/xptcall.cpp:28 cfi
2 xul.dll nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
3 xul.dll void nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
4 xul.dll nsMsgCompFields::Release() comm/mailnews/compose/src/nsMsgCompFields.cpp:62 cfi
5 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 cfi
6 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
7 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
8 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi
9 xul.dll ArrayBufferInputStream::Release() comm/mailnews/addrbook/src/nsAbBooleanExpression.cpp:9 cfi
10 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7506 cfi
11 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7496 cfi
12 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7508 cfi
13 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:76 cfi
14 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
15 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
16 xul.dll nsImapUrl::Release() comm/mailnews/compose/src/nsSmtpUrl.cpp:583 cfi
17 xul.dll nsImapProtocol::~nsImapProtocol() comm/mailnews/imap/src/nsImapProtocol.cpp:662 cfi
18 xul.dll [thunk]:nsImapProtocol::vector deleting destructor'adjustor{24}' (unsigned int) cfi
19 xul.dll nsDSURIContentListener::Release() comm/mailnews/base/util/nsMsgProtocol.cpp:50 frame_pointer
20 xul.dll [thunk]:nsImapProtocol::Release`adjustor{4}' () cfi
21 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1222 frame_pointer
22 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:486 cfi
23 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:303 cfi
24 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:308 cfi
25 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:290 cfi
26 xul.dll nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:454 cfi
27 nss3.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 cfi
28 nss3.dll static unsigned int pr_root(void*) nsprpub/pr/src/md/windows/w95thred.c:137 cfi
29 ucrtbase.dll thread_start<unsigned int (__stdcall*)(void*), 1> cfi
30 kernel32.dll BaseThreadInitThunk cfi
31 mozglue.dll static void patched_BaseThreadInitThunk(int, void*, void*) mozglue/build/WindowsDllBlocklist.cpp:625 cfi
32 ntdll.dll _RtlUserThreadStart cfi
33 ntdll.dll _RtlUserThreadStart cfi

Screenshot corresponding to bug 1517464 comment 40
step 3.

Screenshot corresponding to bug 1517464 comment 40
step 4.

No Umlaut crash in step 3 ( bug 1517464 comment 40 ) while creating folder "Entwürfe" for TB 64bit
beta ( Version 77.0b3 , Build-ID 20200518172851 )
daily ( Version 78.0a1 , Build ID 20200521105808 )

Best regards
Robert

Just to be complete, a note about the same test but with WinXP using TB 52.4.0 (32-Bit):
You cannot save the IMAP draft mail at any place if the network connection was disabled.

This crash can be reproduced only if you have no local draft folder at first.

Earlier you said you see this with German localization. I'm not sure if this mean you don't see it with EN localization? Anyhow, I only have EN localization here. If I remove the Local Folders/Draft in the profile (since you can't just delete it using the UI since it is a "special" folder) and save a draft with network off, it goes OK to Local Folders/Draft-<my account name> like it should with no crash. I did this with a fairly recent Trunk that I built myself and with the 68.7.0 release, both on linux with no crash. Haven't tried with windows.

No Umlaut crash in step 3 ( bug 1517464 comment 40 ) while creating folder "Entwürfe" for TB 64bit
beta ( Version 77.0b3 , Build-ID 20200518172851 )
daily ( Version 78.0a1 , Build ID 20200521105808 )

Are you saying it works OK with the beta and daily but crashes with only the 68.8.1 release?

Just to be complete, a note about the same test but with WinXP using TB 52.4.0 (32-Bit):
You cannot save the IMAP draft mail at any place if the network connection was disabled.

We added the feature to save drafts to local when there is a network problem a few years ago. It may have actually first appeared in TB 60, not sure.

Tried on win10 with tb 68.8.1 64-bit and don't see a crash. So I assume the crash only occurs with DE localization. I then installed the DE localization from TB release archives. Still don't see a crash.

However I did see this:

After restart TB you can see a new local mail folder "Entwürfe" containing the stored Mail.

Of course, since TB didn't crash for me, I didn't have to restart.

But that mail couldn't be opened for reading.
In the Message viewing plane there is written a link "Oder Sie können eine Ausnahme hinzufügen…"
pointing to javascript:showSecuritySection()
Nothing happens if I click on that link.

Rename Folder "Entwürfe" to something else and the saved mail could be read.

I have no idea what is going on with this or what these prompts are about. There is a semi-circle with a dot inside it and a line going to the right (seen in your 2nd screenshot). Almost looks like there is something cut off. The text that translates to "Or you can add an exception" comes from here:
https://searchfox.org/comm-central/rev/566c658a079a9601219ed66f049299fa1bd8b0be/mail/locales/en-US/chrome/overrides/netError.dtd#176

Edit: I tried again with the Local Folder/Drafts (German named) existing. With network off, exact same thing occurred so that doesn't seem to be factor (for me). And, it still doesn't crash. I then installed the EN-US version and the bad folder name still present in Local Folders and has the same problem and, of course, the weird prompts are now in English. I copied the folder to a couple imap accounts. The email inside fails to list at all.

Hi, I tried it with a clean profile inside TB 68.8.1 64-bit with German localization

=> No crash , no semi-circle
but everything else "Entwürfe-<my account name>", not readable draft

Installed Enigmail for that profile
=> No crash
but "semi-circle" and everything else "Entwürfe-<my account name>", not readable draft

(Open test-case: What happen,
a) after compacting from inside Thunderbird in that profile
b) if ccleaner compacts Thunderbird databases from the new profile ... therefor needinfo for me)

no crash but (In reply to Robert Hartmann from comment #47)

(Open test-case: What happen,
a) after compacting from inside Thunderbird in that profile
b) if ccleaner compacts Thunderbird databases from the new profile ... therefor needinfo for me)

compacting TB databases does not change anything.

With newer TB versions no crashes but strange foldernames in TB 68.9.0 and unreadable drafts.

TB 68.9.0 (32-Bit) BuildID 20200602112704 [german]

• without Enigmail :
  "Entwürfe-<my account name>" not readable draft, semi circle
  In the Message viewing plane there is written a link "Oder Sie können eine Ausnahme hinzufügen…"
  pointing to javascript:showSecuritySection()

78.0b1 (32-Bit) BuildID 20200611220825 [german]
"Entwürfe-<my account name>" readable draft

79.0a1 (2020-06-12) (32-bit) BuildID 20200612101437 [en-US]
"Entwürfe-<my account name>" readable draft

68.9.0 (64-Bit) BuildID 20200602112704 [german]

• without Enigmail :
  "Entwürfe-<my account name>" not readable draft, semi circle
  In the Message viewing plane there is written a link "Oder Sie können eine Ausnahme hinzufügen…"
  pointing to javascript:showSecuritySection()

78.0b1 (64-Bit) BuildID 20200611220825 [german]
"Entwürfe-<my account name>" readable draft

79.0a1 (2020-06-12) (64-bit) BuildID 20200612101437 [en-US]
"Entwürfe-<my account name>" readable draft

FYI, I have just encountered this crash in TB 78.0b1 (64-bits) on Windows 10 1909 (64-bits)
bp-b5a18d21-7928-40ba-b11b-be9610200619

It happened shortly after forwarding an email with a .pdf attachment... email was sent successfully and properly saved in IMAP Sent folder (as checked upon re-opening of TB following the crash).

FYI, it seems situation has dramatically worthen in past recent build of TB... and mostly affects Windows users... see attached.

This is an extract of the Signature Report for nsXPCWrappedJS::Release > Aggregations > Build Id

Source: https://crash-stats.mozilla.org/signature/?product=Thunderbird&signature=nsXPCWrappedJS%3A%3ARelease#aggregations

This differences are explained by the fact that you are only looking at 7 days in that query. Change to 30 or 90 days and we see there is no change https://crash-stats.mozilla.org/signature/?product=Thunderbird&signature=nsXPCWrappedJS%3A%3ARelease&date=%3E%3D2020-03-24T16%3A01%3A00.000Z&date=%3C2020-06-24T16%3A01%3A00.000Z#graphs

But thanks for digging into the statistics - very few people do it, and and I wish more did.

Yes the scenario comment 36 reproducible created crashes for me until I cleaned up may GMX-IMAP-Space... so from practical point of view I cannnot reproduce it ...

But let assume we can reproduce it without having to waste GB space on some mail servers...

We need a IMAP-Server which does not tell Thunderbird any quota information (like GMX-Server doesn't do that).
We need a test account on that server with a minimum of IMAP user space.
We should write a mail with attachment and save to draft or let copying the sendet mail to sent-folder. That should be tested in two cases
a) using encryption while sending or saving the draft
b) using no encryption

I think than either the stack trace of this bug 1517464 comment 36 or the stack trace of other bug 1586494 comment 24 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1586494#c24 ) will be reproducible with described secenario .

(In reply to Robert Hartmann from comment #52)

Yes the scenario comment 36 reproducible created crashes for me until I cleaned up may GMX-IMAP-Space... so from practical point of view I cannnot reproduce it ...

Well , just to be fair ... I could not reproduce the crash if internet connected well and GMX is available.

Test case for reproducible crash for Thunderbird 68.12.0 Crash Report [@ nsXPCWrappedJS::Release ]

1. create a mail
2. befor "sending" disconnect (LAN and WLAN) , so that internet and mail-server is not available
3. try to send mail (this doent work - expected warning message is shown)
4. try to save the mail as draft in (unreachable!) IMAP-Folder "Entwürfe" (I thing the crash depends on the umlaut)
5. saving to IMAP doesn't work, choose option save to local

crash happens:
32 bit : bp-568b1d7a-cc20-4d23-b5bf-9c5760200909
64 bit: no crash because "infinity loop" downloading mails while no internet connection : that is starting IMAP sync with internet connected (many mails) and while disconnected internet the loop bound 406 mails of 34 downloaded as status counter ...

stack trace for 32 bit TB version on Windows 10 home 64 bit:
Crashing Thread (70)
Frame Module Signature Source Trust
0 xul.dll nsXPCWrappedJS::Release() js/xpconnect/src/XPCWrappedJS.cpp:256 context
1 xul.dll static unsigned long ReleaseThunk(struct IUnknown*) xpcom/reflect/xptcall/xptcall.cpp:28 cfi
2 xul.dll nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
3 xul.dll void nsMsgCompFields::~nsMsgCompFields() comm/mailnews/compose/src/nsMsgCompFields.cpp:92 cfi
4 xul.dll nsMsgCompFields::Release() comm/mailnews/compose/src/nsMsgCompFields.cpp:62 cfi
5 xul.dll nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:303 cfi
6 xul.dll void nsMsgComposeAndSend::~nsMsgComposeAndSend() comm/mailnews/compose/src/nsMsgSend.cpp:282 cfi
7 xul.dll nsMsgComposeAndSend::Release() comm/mailnews/compose/src/nsMsgSend.cpp:243 cfi
8 xul.dll void CopyListener::~CopyListener() comm/mailnews/compose/src/nsMsgCopy.cpp:41 cfi
9 xul.dll ArrayBufferInputStream::Release() comm/mailnews/addrbook/src/nsAbBooleanExpression.cpp:9 cfi
10 xul.dll nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7516 cfi
11 xul.dll void nsImapMailCopyState::~nsImapMailCopyState() comm/mailnews/imap/src/nsImapMailFolder.cpp:7506 cfi
12 xul.dll mozilla::TransceiverImpl::Release() comm/mailnews/imap/src/nsImapMailFolder.cpp:7518 cfi
13 xul.dll nsImapUrl::~nsImapUrl() comm/mailnews/imap/src/nsImapUrl.cpp:76 cfi
14 xul.dll [thunk]:nsImapUrl::vector deleting destructor'adjustor{8}' (unsigned int) cfi
15 xul.dll nsMsgMailNewsUrl::Release() comm/mailnews/base/util/nsMsgMailNewsUrl.cpp:81 frame_pointer
16 xul.dll nsImapUrl::Release() comm/mailnews/compose/src/nsSmtpUrl.cpp:583 cfi
17 xul.dll nsImapProtocol::~nsImapProtocol() comm/mailnews/imap/src/nsImapProtocol.cpp:662 cfi
18 xul.dll [thunk]:nsImapProtocol::vector deleting destructor'adjustor{24}' (unsigned int) cfi
19 xul.dll nsDSURIContentListener::Release() comm/mailnews/base/util/nsMsgProtocol.cpp:50 frame_pointer
20 xul.dll [thunk]:nsImapProtocol::Release`adjustor{4}' () cfi
21 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1222 frame_pointer
22 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:486 cfi
23 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:303 cfi
24 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:308 cfi
25 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:290 cfi
26 xul.dll nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:454 cfi
27 nss3.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 cfi
28 nss3.dll static unsigned int pr_root(void*) nsprpub/pr/src/md/windows/w95thred.c:137 cfi
29 ucrtbase.dll thread_start<unsigned int (__stdcall*)(void*), 1> cfi
30 kernel32.dll BaseThreadInitThunk cfi
31 mozglue.dll static void patched_BaseThreadInitThunk(int, void*, void*) mozglue/build/WindowsDllBlocklist.cpp:625 cfi
32 ntdll.dll _RtlUserThreadStart cfi
33 ntdll.dll _RtlUserThreadStart cfi

A few months back you were testing against 78.0b. Have you tried with 78.2.1 or still not using 78.x series because of legacy extensions?

(In reply to Arthur K. from comment #54)

A few months back you were testing against 78.0b. Have you tried with 78.2.1 or still not using 78.x series because of legacy extensions?

Hi Arthur, in release channel I am using Enigmail - so until there is no automatical upgrade away vom TB 68.* my default TB stay at 68.*.

But sure I can test TB beta and daily/nightly in 32bit and 64 bit just doing the same procedure.
May be it is possible to install 78.2.1 in parallel to 68.* using a fresh profile?
Than I can test it with 78.2.1, too.

Best regards

(In reply to Robert Hartmann from comment #55)

(In reply to Arthur K. from comment #54)

A few months back you were testing against 78.0b. Have you tried with 78.2.1 or still not using 78.x series because of legacy extensions?

Hi Arthur, in release channel I am using Enigmail - so until there is no automatical upgrade away vom TB 68.* my default TB stay at 68.*.

But sure I can test TB beta and daily/nightly in 32bit and 64 bit just doing the same procedure.
May be it is possible to install 78.2.1 in parallel to 68.* using a fresh profile?
Than I can test it with 78.2.1, too.

Best regards

I see. If you do go to newer TB, remember that it will make it so your profile cannot go back to TB 68 version. You could back up your profile and test or, as you say, create a new profile with which to test to keep your old one safe from changes.

Looking at the Enigmail announcement here (https://sourceforge.net/p/enigmail/forum/announce/thread/7dcd29e5f9/), there will be no newer version.

I typically back up my profile by doing Help > Troubleshooting Information > clicking about:profiles > clicking Open Folder for both Root Directory and Local Directory and, using 7-Zip, to highlight and back up the entire folder contents.

(In reply to Robert Hartmann from comment #53)

(In reply to Robert Hartmann from comment #52)

Yes the scenario comment 36 reproducible created crashes for me until I cleaned up may GMX-IMAP-Space... so from practical point of view I cannnot reproduce it ...

Well , just to be fair ... I could not reproduce the crash if internet connected well and GMX is available.

Test case for reproducible crash for Thunderbird 68.12.0 Crash Report [@ nsXPCWrappedJS::Release ]

1. create a mail
2. befor "sending" disconnect (LAN and WLAN) , so that internet and mail-server is not available
3. try to send mail (this doent work - expected warning message is shown)
4. try to save the mail as draft in (unreachable!) IMAP-Folder "Entwürfe" (I thing the crash depends on the umlaut)
5. saving to IMAP doesn't work, choose option save to local

crash happens:
32 bit : bp-568b1d7a-cc20-4d23-b5bf-9c5760200909
64 bit: no crash because "infinity loop" downloading mails while no internet connection : that is starting IMAP sync with internet connected (many mails) and while disconnected internet the loop bound 406 mails of 34 downloaded as status counter ...

Here on Windows 10 64bit Version 2004 (Build 19041.508) testing with newer TB versions
TB 32bit + TB 64bit : 78.2.2 german Build 20200908210243, 81.0b3 german Build 20200908000014, 82.0a1 english 20200914104010
I cannot reproduce the crash with the above steps.

This time in all tested versions there was no crash while saving to the local fallback folder "Entwüfe-<MY-EMAIL-ADRESS> while online draft folder "Entwürfe" at GMX was not available because of disconnected internet. And the Umlaut "ü" was created correct and not as broken UTF-8 to Latin mistranscoded "Entwürfe-<my account name>". But mails in that via TB 68.* created folder with broken name are not readable.

Thunderbird 78.4.1 crashed today right after sending an e-mail with the signature nsXPCWrappedJS::Release, see id c1fa773e-5853-49c5-8371-396ac0201114
I cannot remember having a crash right after sending an e-mail in Thunderbird 68 or earlier versions.

(In reply to tcl_de from comment #58)

Thunderbird 78.4.1 crashed today right after sending an e-mail with the signature nsXPCWrappedJS::Release, see id c1fa773e-5853-49c5-8371-396ac0201114
I cannot remember having a crash right after sending an e-mail in Thunderbird 68 or earlier versions.

just add "bp" to your crash id , to become clickable in bugzilla: bp-c1fa773e-5853-49c5-8371-396ac0201114

FYI, I have encountered this crash in TB 88.0b2 (64-bit) [and possibly TB 88.0b1 (64-bit) but no crash report generated at the time]
bp-e99b3592-f699-469c-b750-d9cde0210407

(In reply to Richard Leger from comment #60)

FYI, I have encountered this crash in TB 88.0b2 (64-bit) [and possibly TB 88.0b1 (64-bit) but no crash report generated at the time]
bp-e99b3592-f699-469c-b750-d9cde0210407

Were you sending mail? If not, what?

Arthur, can you reproduce using comment 52?

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

Arthur, can you reproduce using comment 52?

I cannot but I don't have that much email consuming up my GMail account that I'd reach this threshold.

Mainly notes to myself here:

(In reply to Richard Leger from comment #60)

FYI, I have encountered this crash in TB 88.0b2 (64-bit) [and possibly TB 88.0b1 (64-bit) but no crash report generated at the time]
bp-e99b3592-f699-469c-b750-d9cde0210407

Looking at the call stack on that crash, it's dying because an nsMsgCopy being destructed, and is releasing something on the imap thread (or at least, not on the main thread)...

The candidates are:

nsCOMPtr<nsIMsgFolder> mDstFolder;
nsCOMPtr<nsIMsgDBHdr> mMsgToReplace;
nsCOMPtr<nsIMsgSend> mMsgSendObj;

I'd guess it was the nsIMsgSend, which (I think) has recently been converted into javascript. And you can't release JS objects except on the main thread (in fact the crash is not really a crash, it's an assertion: https://searchfox.org/mozilla-central/source/js/xpconnect/src/XPCWrappedJS.cpp#258 )

HOWEVER. Looking right down to the bottom of the call stack, I can see the root of it all is TerminateProcessOnMemoryExhaustion, which kind of implies that we're shutting down because we ran out of memory. In this case, I suspect that a lot of the careful (ha!) shutdown ordering flies out the window, and everything on the main thread releases nsIMsgSend before the IMAP thread finishes up... Sigh. I hate refcounted pointers :-(

Anyway, given that it was an out-of-memory-shut-everything-down-in-a-wild-panic situation, even if the assert hadn't triggered, the app would have crashed, for all intents and purposes.
So I think the best approach would be to figure out what was causing the out-of-memory in the first place. I'd guess something ended up in a runaway-memory use situation. No idea what though... anyone have any thoughts as to how we might be able to replicate this bug?

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

(In reply to Richard Leger from comment #60)

FYI, I have encountered this crash in TB 88.0b2 (64-bit) [and possibly TB 88.0b1 (64-bit) but no crash report generated at the time]
bp-e99b3592-f699-469c-b750-d9cde0210407

Were you sending mail? If not, what?

If it followed an action from my part I would have put a note in the crash report, are you able to access it to check? If not it means TB would have crashed by itself...

If it followed an action from my part I would have put a note in the crash report, are you able to access it to check?

Sorry, comments submitted in crash reports are not visible to us.

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

If it followed an action from my part I would have put a note in the crash report, are you able to access it to check?

Sorry, comments submitted in crash reports are not visible to us.

Sorry I don't recall for that particular crash report... I may have been sending, copying or doing nothing at the time... not exactly sure... till now I always put the last action prior crash in the comment of crash report... I think it would be helpfull for few TB dev people to be granted access to that field in crash report... as it is more likely where people may leave manually info about the crash. I know I always do... thinking it would help you identify the reason of the crash... I'll try to remember to indicate in along link to crash report in bug report in the future... but for this one it has been too long...

This comment covers behavior of TB 32bit release Version 78.13.0, Build-ID 20210802223056 on Windows 10 Home 20H2 64bit
(In reply to Robert Hartmann from comment #57)

(In reply to Robert Hartmann from comment #53)

(In reply to Robert Hartmann from comment #52)

Yes the scenario comment 36 reproducible created crashes for me until I cleaned up may GMX-IMAP-Space...
so from practical point of view I cannnot reproduce it ...

Well , just to be fair ... I could not reproduce the crash if internet connected well and GMX is available.

Test case for reproducible crash for Thunderbird 68.12.0 Crash Report [@ nsXPCWrappedJS::Release ]

1. create a mail
2. befor "sending" disconnect (LAN and WLAN) , so that internet and mail-server is not available
3. try to send mail (this doent work - expected warning message is shown)
4. try to save the mail as draft in (unreachable!) IMAP-Folder "Entwürfe" (I thing the crash depends on the umlaut)
5. saving to IMAP doesn't work, choose option save to local

crash happens:
32 bit : bp-568b1d7a-cc20-4d23-b5bf-9c5760200909
64 bit: no crash because "infinity loop" downloading mails while no internet connection : that is starting IMAP sync
with internet connected (many mails) and while disconnected internet the loop bound 406 mails of 34 downloaded as status counter ...

Here on Windows 10 64bit Version 2004 (Build 19041.508) testing with newer TB versions
TB 32bit + TB 64bit : 78.2.2 german Build 20200908210243, 81.0b3 german Build 20200908000014, 82.0a1 english 20200914104010
I cannot reproduce the crash with the above steps.

This time in all tested versions there was no crash while saving to the local fallback folder "Entwüfe-<MY-EMAIL-ADRESS>
while online draft folder "Entwürfe" at GMX was not available because of disconnected internet.
And the Umlaut "ü" was created correct and not as broken UTF-8 to Latin mistranscoded "Entwürfe-<my account name>".
But mails in that via TB 68.* created folder with broken name are not readable.

I retry my above steps and thought I found a strange TB behavior
(TB 32bit release Version 78.13.0, Build-ID 20210802223056 on Windows 10 Home 20H2 64bit)
without a crash:
In step 5 TB now create a draft mail in local fallback folder which is crypted with openPGP but its decryption takes very long ... mutiple minutes.
I thought the mail was stored empty on disk or couldnt become display... therefor I search for this bug to add a new comment. And while I am writing this comment the decryption process finished its work an the draft gets displayed correctly.

smtp-js seems to have resolved most of this, thanks to the work of rnons and others.

NS_CycleCollectorSuspect3

• signature is gone because it was added as a signature prefix (for all releases) as of 2021-04-21 via bug 1705027. Prior to that date, the crash rate peaks at ~2.4k per day.
• mccr8 kindly created follow up bug reports:
  ** Bug 1707004 - Crash in [@ NS_CycleCollectorSuspect3 | XULContentSinkImpl::Release] via nsMsgComposeAndSend::~nsMsgComposeAndSend - still a topcrash for version 78 (#4), but so far no crashes newer than version 85
  ** Bug 1707006 - Crash in [@ NS_CycleCollectorSuspect3 | IdleRequestExecutor::Release] via nsMsgComposeAndSend::~nsMsgComposeAndSend - still a topcrash for version 78 (#7), but so far no crashes newer than version 78
  ** Bug 1707007 - Crash in [@ NS_CycleCollectorSuspect3 | nsGlobalWindowOuter::Release] via nsMsgComposeAndSend::~nsMsgComposeAndSend - still a topcrash for version 78 (#30), but so far [no crashes newer than version 78](https://crash-stats.mozilla.org/signature/?signature=NS_CycleCollectorSuspect3%20%7C%20nsGlobalWindowOuter%3A%3ARelease&date=%3E%3D2021-03-05T16%3A44%3A00.000Z&date=%3C2021-09-05T16%3A44%3A00.000Z#summary
• All of the above crashes are via nsMsgComposeAndSend::~nsMsgComposeAndSend and so this data suggests the signature is gone (unless the signatures morphed) because of smtp-js, which came in 88 beta and was the current beta in april 2021 when the signature prefix took effect

nsXPCWrappedJS::Release

• is #1 crash for version 78, but is #3 in version 91, suggesting that it too is impacted by smtp-js
• the crashes that remain in version 91 are via various combinations of CopyListener::~CopyListener, ArrayBufferInputStream::Release, nsImapMailCopyState::~nsImapMailCopyState - I will file new bugs for those if needed.

Yes let's close this and continue in the other bugs.

Been a while but I hit this nsXPCWrappedJS::Release the other day. Should I open a new bug?

https://crash-stats.thunderbird.net/report/bp-4fcf0c41-1d9d-49db-9012-080020211108

(In reply to Arthur K. [He/Him] from comment #71)

Been a while but I hit this nsXPCWrappedJS::Release the other day. Should I open a new bug?

https://crash-stats.thunderbird.net/report/bp-4fcf0c41-1d9d-49db-9012-080020211108

I think bug 1742991