all crashes are TB19 beta. speculative - regression of bug 776630? but low crash rate This bug was filed from the Socorro interface and is report bp-795b5954-31de-492b-9049-991ee2130121 . ============================================================= 0 xul.dll nsMsgDatabase::CopyHdrFromExistingHdr mailnews/db/msgdb/src/nsMsgDatabase.cpp:3462 1 xul.dll nsParseNewMailState::MoveIncorporatedMessage mailnews/local/src/nsParseMailbox.cpp:2528 2 xul.dll nsParseNewMailState::ApplyFilterHit mailnews/local/src/nsParseMailbox.cpp:2089 3 xul.dll nsMsgFilterList::ApplyFiltersToHdr mailnews/base/search/src/nsMsgFilterList.cpp:315 4 xul.dll nsParseNewMailState::ApplyFilters mailnews/local/src/nsParseMailbox.cpp:1974 5 xul.dll nsParseNewMailState::PublishMsgHeader mailnews/local/src/nsParseMailbox.cpp:1895 6 xul.dll nsPop3Sink::IncorporateComplete mailnews/local/src/nsPop3Sink.cpp:873 7 xul.dll nsPop3Protocol::HandleLine mailnews/local/src/nsPop3Protocol.cpp:3524

p.s. every one I looked at has pop on the stack

filter related?

bp-c6bd5571-79a4-4904-ad83-2d75d2130224 has a reporter email address but no comments :( Over 50% of crashes are from just a couple users.

bp-448b3098-a7c3-470c-aea8-acb2f2130323 TB21.0a2 smiffmail has lots of crashes, all startup however the older crashes from a month or two (like v19 beta) where interesting because 70% of crashes happened in the 10-13 minute time period. I think TB19 beta is the earliest crash I found

looks like only one, or at most 3 users in current beta. I don't think this is worth tracking/pursuing unless the rate goes up or smiffmail finds a way to reproduce.

however, it is common in Seamonkey 2.17.1. for example bp-e41f6699-8657-4ee4-9539-1082f2130611 So removing from closeme list. TBird 19 beta bp-291ffbf4-f09b-4287-8e17-5c6822130224 user says the folder was missing write permissions.

bp-37c66fad-3d90-47d8-8ca8-996f72130117 is TB17 Mac @ nsMsgDatabase::CopyHdrFromExistingHdr but I'm not sure it's the same stack pinged a few crash reporters.

(In reply to Wayne Mery (:wsmwk) from comment #6) > however, it is common in Seamonkey 2.17.1. for example > bp-e41f6699-8657-4ee4-9539-1082f2130611 > So removing from closeme list. > > TBird 19 beta bp-291ffbf4-f09b-4287-8e17-5c6822130224 user says the folder > was missing write permissions. Any idea why this is more common in SM? Or why it happens in the first place?

bp-c6bd5571-79a4-4904-ad83-2d75d2130224 reported to me "missing write permissions on the folder." Unclear to me if that meant .msf or the mail folder.

Nothing obvious I can see in nsMsgDatabase::CopyHdrFromExistingHdr . Maybe we could check rv from CreateNewHdr() and the various casts make me feel strange. Also, CopyHdrFromExistingHdr() returns success if a null existingHdr is passed in and sets no newHdr in that case. Shouldn't it fail in that case? Does anybody see any value in these proposed changes? Even after that, how can we test if it help anything? The stack seems to indicate this happens when a filter tries to move a message. Wayne, can you determine if the users have maildir as their storage?

definitely regression... #13 - topcrash for TB24.1.0 and 24.0.1 ~#20 for TB24.0 back in September > Wayne, can you determine if the users have maildir as their storage? sorry missed your message. I'll check but given it's a topcrash I think it's doubtful all are maildir

I get the crash after doing the following: Two accounts: One account is accessing a GMX-mail-address via IMAP. The other is accessing the same address via POP3, for storing the mails on one machine. And one filter-rule on the POP3-account for moving mails with a certain sender to a local folder during fetching the mails from the server. On the IMAP-account of a mail-address, I have moved a couple messages around between the inbox and the other folders and back. Afterwards, when I fetch the mails with the POP3-account, I get the error mentioned earlier. Then it can happen that I have a few mails in the POP3-account, which still are visible in the IMAP-account. So these mails were cloned somehow. The error does not happen when the filter is temporarily disabled.

What I forgot to mention: After getting the mails via POP3 with the filter disabled, moving the messages which would have been filtered to the local folder does not trigger the error and crash.

still a topcrash. would be nice to find someone who crashes often/reliably enough that they could find the regression range :) bp-2d9d2756-5eb1-442c-8edb-a8d2a2150421 " Every time I fetch my mails, a message pops up, telling me that mails couldn't be filtered due to possibly missing write privileges or running out of available disk space. I double checked both, there are 19 GB of disk space available and I have read/write permissions on all files, on folders also execute-permission. After clicking on OK on the mentioned message Thunderbird crashes. Maybe there is a problem that two threads want to write on the same file but this should never lead to a crash :-/ "

This Mac user https://support.mozilla.org/en-US/questions/1067526 resolved crashes by repairing folder. bp-0e0aa3d2-87ec-4541-948f-b3c6b215061 nsMsgDatabase::CopyHdrFromExistingHdr(unsigned int, nsIMsgDBHdr*, bool, nsIMsgDBHdr**) OOM | small bp-6c0a0441-7a01-481b-9bf6-de7482140728

just had someone pop up in support with this crash. Before any file changes are made diagnosing and trying to work it out. Is their anything that might be useful from the user? I think a corrupt MSF might be the issue as this guys issues just started yesterday.

Not sure Matt about diagnosing, but it should be fairly easy to at least stop the crash with this patch.

Comment on attachment 8628323 [details] [diff] [review] Null check row http://hg.mozilla.org/comm-central/rev/1d7c204371a7 We'll also uplift this.

http://hg.mozilla.org/releases/comm-aurora/rev/6afc64f15c3c http://hg.mozilla.org/releases/comm-beta/rev/716e805c17d3 http://hg.mozilla.org/releases/comm-esr38/rev/d3ba1db5d366

http://hg.mozilla.org/releases/comm-release/rev/04286406c5bf SEAMONKEY_2_35_RELEASE_BRANCH