crash [@ nsFolderCompactState::CleanupTempFilesAfterError()] not new in v3.1.7. all Mac bp-5d7fd970-ab20-453c-8a49-d1c5d2101213 EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE 0x4c 0 thunderbird-bin nsFolderCompactState::CleanupTempFilesAfterError mailnews/base/src/nsMsgFolderCompactor.cpp:113 1 thunderbird-bin thunderbird-bin@0xa65568 2 thunderbird-bin nsFolderCompactState::Release mailnews/base/src/nsMsgFolderCompactor.cpp:71 3 libxpcom_core.dylib libxpcom_core.dylib@0x3f93 4 thunderbird-bin thunderbird-bin@0x68c9e 5 thunderbird-bin nsStreamListenerTee::Release netwerk/base/src/nsStreamListenerTee.cpp:40 6 libxpcom_core.dylib nsCOMPtr_base::assign_with_AddRef xpcom/glue/nsCOMPtr.h:456 7 thunderbird-bin nsImapMockChannel::Close 8 thunderbird-bin thunderbird-bin@0xb815b7 9 thunderbird-bin nsImapMockChannel::Release mailnews/imap/src/nsImapProtocol.cpp:8575 10 thunderbird-bin nsCacheListenerEvent::Run netwerk/cache/src/nsCacheService.cpp:1096

bp-00cf888a-7b88-42a4-8ffd-882c52110805 EXC_BAD_ACCESS / KERN_INVALID_ADDRESS 0x82 Ordner wurden komprimiert, dabei kam der Absturz Folder have been compressed, it came the crash 0 XUL nsFolderCompactState::CleanupTempFilesAfterError mailnews/base/src/nsMsgFolderCompactor.cpp:113 1 XUL nsFolderCompactState::~nsFolderCompactState mailnews/base/src/nsMsgFolderCompactor.cpp:94 2 XUL nsFolderCompactState::Release mailnews/base/src/nsMsgFolderCompactor.cpp:71 3 XUL nsStreamListenerTee::~nsStreamListenerTee 4 XUL nsStreamListenerTee::Release netwerk/base/src/nsStreamListenerTee.cpp:40 5 XUL nsImapMockChannel::Close 6 XUL nsImapMockChannel::~nsImapMockChannel mailnews/imap/src/nsImapProtocol.cpp:8728

also increased in version 5. though not as frequent as other compact crashes.

My guess is that this happens when we're compacting an offline store, and a message in the folder is not in the offline store, but is in the disk/memory cache, so we try to stream it to write to the new, compacted offline store. I've tried to reproduce that scenario but it hasn't led to any crashes. But that scenario is a bit tricky to reproduce, so I'll have to do a bit of debugging to see if I've actually reproduced it. Normally, we don't hit the ::Close() call in the destructor of the mock channel, and I haven't reproduced that.

In last 6 months, no crashes newer than version 17.0.8. for example bp-3b01b650-e969-4143-afe8-7ca5f2140210