I'm getting bitten by this crash in `[@ nsMsgLocalMailFolder::FinishNewLocalMessage ]`, this time it's `m_msgStore` that's null. There's a way to consistently repro, by changing the number of messages generated in the test from [D183880](https://phabricator.services.mozilla.com/D183880) (`browser_archive.js:35`) from 2 to 5. From spending some time investigating this specific occurrence of the crash, it looks like when copying the 3rd message, the call to `nsMsgLocalMailFolder::InitCopyMsgHdrAndFileStream` fails with this warning: ``` [Parent 13229, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, (nsresult)(((uint32_t)(1) << 31) | ((uint32_t)(16 + 69) << 16) | ((uint32_t)(22)))) failed with result 0x80004005 (NS_ERROR_FAILURE): file /[...]/mozilla-central/comm/mailnews/base/src/nsMsgDBFolder.cpp:731 ``` The interesting bit of backtrace from the `nsMsgLocalMailFolder::InitCopyMsgHdrAndFileStream` that generates this warning (as per gdb) is: ``` #0 nsMsgLocalMailFolder::InitCopyMsgHdrAndFileStream() (this=0x7fffabc9d100) at /[...]/mozilla-central/comm/mailnews/local/src/nsLocalMailFolder.cpp:1890 #1 0x00007fffed8cfdd0 in nsMsgLocalMailFolder::StartMessage() (this=0x0) at /[...]/mozilla-central/comm/mailnews/local/src/nsLocalMailFolder.cpp:2435 #2 0x00007fffed8da3c8 in nsMailboxProtocol::OnStopRequest(nsIRequest*, nsresult) (this=0x7fffa7d144c0, request=0x7fffa8182c50, aStatus=nsresult::NS_OK) at /[...]/mozilla-central/comm/mailnews/local/src/nsMailboxProtocol.cpp:246 #3 0x00007fffe86e3a10 in nsInputStreamPump::OnStateStop() (this=this@entry=0x7fffa8182c50) at /[...]/mozilla-central/netwerk/base/nsInputStreamPump.cpp:695 #4 0x00007fffe86e2e6a in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7fffa8182c50, stream=<optimized out>) at /[...]/mozilla-central/netwerk/base/nsInputStreamPump.cpp:415 #5 0x00007fffe86e3bc5 in non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () at /[...]/mozilla-central/netwerk/base/nsInputStreamPump.cpp:671 ``` After this call, `mCopyState->m_msgStore` becomes null. So from the look of it, something is causing retrieving the server to fail, which in turns causes `m_msgStore` (and maybe a few other bits) to become null (`m_msgStore` was definitely not null before this).
Bug 1749276 Comment 63 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I'm getting bitten by this crash in `[@ nsMsgLocalMailFolder::FinishNewLocalMessage ]`, this time it's `m_msgStore` that's null. There's a way to consistently repro, by changing the number of messages generated in the test from [D183880](https://phabricator.services.mozilla.com/D183880) (`browser_archive.js:35`) from 2 to 5. The crash happens when trying to archive messages (`browser_archive.js:65`). From spending some time investigating this specific occurrence of the crash, it looks like when copying the 3rd message, the call to `nsMsgLocalMailFolder::InitCopyMsgHdrAndFileStream` fails with this warning: ``` [Parent 13229, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, (nsresult)(((uint32_t)(1) << 31) | ((uint32_t)(16 + 69) << 16) | ((uint32_t)(22)))) failed with result 0x80004005 (NS_ERROR_FAILURE): file /[...]/mozilla-central/comm/mailnews/base/src/nsMsgDBFolder.cpp:731 ``` The interesting bit of backtrace from the `nsMsgLocalMailFolder::InitCopyMsgHdrAndFileStream` that generates this warning (as per gdb) is: ``` #0 nsMsgLocalMailFolder::InitCopyMsgHdrAndFileStream() (this=0x7fffabc9d100) at /[...]/mozilla-central/comm/mailnews/local/src/nsLocalMailFolder.cpp:1890 #1 0x00007fffed8cfdd0 in nsMsgLocalMailFolder::StartMessage() (this=0x0) at /[...]/mozilla-central/comm/mailnews/local/src/nsLocalMailFolder.cpp:2435 #2 0x00007fffed8da3c8 in nsMailboxProtocol::OnStopRequest(nsIRequest*, nsresult) (this=0x7fffa7d144c0, request=0x7fffa8182c50, aStatus=nsresult::NS_OK) at /[...]/mozilla-central/comm/mailnews/local/src/nsMailboxProtocol.cpp:246 #3 0x00007fffe86e3a10 in nsInputStreamPump::OnStateStop() (this=this@entry=0x7fffa8182c50) at /[...]/mozilla-central/netwerk/base/nsInputStreamPump.cpp:695 #4 0x00007fffe86e2e6a in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7fffa8182c50, stream=<optimized out>) at /[...]/mozilla-central/netwerk/base/nsInputStreamPump.cpp:415 #5 0x00007fffe86e3bc5 in non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () at /[...]/mozilla-central/netwerk/base/nsInputStreamPump.cpp:671 ``` After this call, `mCopyState->m_msgStore` becomes null. So from the look of it, something is causing retrieving the server to fail, which in turns causes `m_msgStore` (and maybe a few other bits) to become null (`m_msgStore` was definitely not null before this).