The maildir code doesn't do enough error checking. For this case it looks like the code alerts you and crashes anyway: mailnews/local/src/nsMsgMaildirStore.cpp https://dxr.mozilla.org/comm-central/source/mailnews/local/src/nsMsgMaildirStore.cpp#794 Starting with line 794: nsCOMPtr<nsIMsgDBHdr> newHdr; if (destMailDB) rv = destMailDB->CopyHdrFromExistingHdr(nsMsgKey_None, aHdr, true, getter_AddRefs(newHdr)); if (NS_SUCCEEDED(rv) && !newHdr) rv = NS_ERROR_UNEXPECTED; if (NS_FAILED(rv)) { aDestFolder->ThrowAlertMsg("filterFolderHdrAddFailed", nullptr); return rv; } There's a similar case where we crashed on a developer machine; it just logs a debug warning and crashes: mailnews/local/src/nsMsgMaildirStore.cpp https://dxr.mozilla.org/comm-central/source/mailnews/local/src/nsMsgMaildirStore.cpp#589 Starting with line 589 nsCOMPtr<nsIMsgDatabase> db; aFolder->GetMsgDatabase(getter_AddRefs(db)); if (!db) NS_ERROR("no db");

Stack: Frame Module Signature [Expand] Source 0 xul.dll nsMsgMaildirStore::MoveNewlyDownloadedMessage nsMsgMaildirStore.cpp:835 1 xul.dll nsParseNewMailState::ApplyFilterHit nsParseMailbox.cpp:2255 2 xul.dll nsMsgFilterList::ApplyFiltersToHdr nsMsgFilterList.cpp:326 3 xul.dll nsParseNewMailState::ApplyFilters nsParseMailbox.cpp:2135 4 xul.dll nsParseNewMailState::PublishMsgHeader nsParseMailbox.cpp:2060 5 xul.dll nsPop3Sink::IncorporateComplete nsPop3Sink.cpp:906 6 xul.dll nsPop3Protocol::HandleLine nsPop3Protocol.cpp:3570 7 xul.dll nsPop3Protocol::RetrResponse nsPop3Protocol.cpp:3355 8 xul.dll nsPop3Protocol::ProcessProtocolState nsPop3Protocol.cpp:3986 9 xul.dll nsMsgProtocol::OnDataAvailable nsMsgProtocol.cpp:298 10 xul.dll nsInputStreamPump::OnStateTransfer nsInputStreamPump.cpp:600 11 xul.dll nsInputStreamPump::OnInputStreamReady nsInputStreamPump.cpp:429 12 xul.dll nsInputStreamReadyEvent::Run nsStreamUtils.cpp:95

Interesting find. So your crash was with 52.7.0?

No, with code based on Thunderbird 52.0.

So far, we know of only a single user who has this crash. It might be a corrupted maildir, or something like that. If we get more user reports, I'll update.

Well, bug 1264673 landed in 52.6.0 which fixed such a crash. And the code you cited in comment 0 is 52.6.0, not 52.0

Hmm, how can it still crash? https://hg.mozilla.org/comm-central/rev/f9c68d3f6054#l1.12

(In reply to Jorg K (GMT+2) from comment #6) > Hmm, how can it still crash? > https://hg.mozilla.org/comm-central/rev/f9c68d3f6054#l1.12 Ben, am I mistaken about comment 5?