The default bug view has changed. See this FAQ.

crash in nsMsgDatabase::CopyHdrFromExistingHdr with filters

RESOLVED FIXED in Thunderbird 42.0

Status

MailNews Core
Database
--
critical
RESOLVED FIXED
4 years ago
a year ago

People

(Reporter: wsmwk, Assigned: rkent)

Tracking

({crash, regression, topcrash-thunderbird})

Trunk
Thunderbird 42.0
x86
All
crash, regression, topcrash-thunderbird

Thunderbird Tracking Flags

(thunderbird39 wontfix, thunderbird40 fixed, thunderbird41 fixed, thunderbird42 fixed, thunderbird_esr3839+ fixed, seamonkey2.35 fixed)

Details

(Whiteboard: [startupcrash][regression:TB19], crash signature, URL)

Attachments

(1 attachment)

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.
Whiteboard: [closeme 2013-06-10][rare]
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.
Whiteboard: [closeme 2013-06-10][rare] → [rare][startupcrash]
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.
Crash Signature: [@ nsMsgDatabase::CopyHdrFromExistingHdr(unsigned int, nsIMsgDBHdr*, bool, nsIMsgDBHdr**)] → [@ nsMsgDatabase::CopyHdrFromExistingHdr(unsigned int, nsIMsgDBHdr*, bool, nsIMsgDBHdr**)] [@ nsMsgDatabase::CopyHdrFromExistingHdr ]
OS: Windows NT → All
(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?
Flags: needinfo?(mnyromyr)
Flags: needinfo?(acelists)
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.

Comment 10

4 years ago
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?
Flags: needinfo?(acelists)
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
Keywords: topcrash-thunderbird
Whiteboard: [rare][startupcrash] → [startupcrash][regression:TB19]

Comment 12

3 years ago
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.

Comment 13

3 years ago
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 :-/ "
Summary: crash in nsMsgDatabase::CopyHdrFromExistingHdr → crash in nsMsgDatabase::CopyHdrFromExistingHdr with filters
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

Comment 16

2 years ago
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.
(Assignee)

Comment 17

2 years ago
Created attachment 8628323 [details] [diff] [review]
Null check row

Not sure Matt about diagnosing, but it should be fairly easy to at least stop the crash with this patch.
Assignee: nobody → rkent
Status: NEW → ASSIGNED
Attachment #8628323 - Flags: review?(neil)

Updated

2 years ago
Attachment #8628323 - Flags: review?(neil) → review+
(Assignee)

Updated

2 years ago
tracking-thunderbird_esr38: --- → +
(Assignee)

Comment 18

2 years ago
Comment on attachment 8628323 [details] [diff] [review]
Null check row

http://hg.mozilla.org/comm-central/rev/1d7c204371a7

We'll also uplift this.
Attachment #8628323 - Flags: approval-comm-esr38+
Attachment #8628323 - Flags: approval-comm-beta+
Attachment #8628323 - Flags: approval-comm-aurora+
(Assignee)

Updated

2 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-thunderbird39: --- → wontfix
status-thunderbird40: --- → affected
status-thunderbird41: --- → affected
status-thunderbird42: --- → fixed
status-thunderbird_esr38: --- → affected
tracking-thunderbird_esr38: + → 39+
Resolution: --- → FIXED
(Assignee)

Comment 19

2 years ago
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
status-thunderbird40: affected → fixed
status-thunderbird41: affected → fixed
status-thunderbird_esr38: affected → fixed

Updated

2 years ago
Target Milestone: --- → Thunderbird 42.0

Updated

2 years ago
Blocks: 1177041

Comment 20

2 years ago
http://hg.mozilla.org/releases/comm-release/rev/04286406c5bf SEAMONKEY_2_35_RELEASE_BRANCH
status-seamonkey2.35: --- → fixed
Keywords: regressionwindow-wanted
(Reporter)

Updated

a year ago
Flags: needinfo?(mnyromyr)
You need to log in before you can comment on or make changes to this bug.