crash in nsMsgDBFolder::NotifyPropertyFlagChanged deleting or moving messages, with (mostly) random addresses

NEW
Unassigned

Status

MailNews Core
Backend
--
critical
6 years ago
7 months ago

People

(Reporter: wsmwk, Unassigned)

Tracking

(Blocks: 2 bugs, {crash, regression, regressionwindow-wanted})

Trunk
x86
All
crash, regression, regressionwindow-wanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [regression:TB12], crash signature)

(Reporter)

Description

6 years ago
#40 crash for version 13
regression, starting in version 12.

This bug was filed from the Socorro interface and is 
report bp-3b63f5aa-37c6-46c0-af4d-629a02120705 .
============================================================= 

bp-3b63f5aa-37c6-46c0-af4d-629a02120705
I was deleting an email; it wasn't finished loading its content, but that shouldn't be a factor.

bp-80377ecd-bc16-4360-8295-fb4702120719
A suspect email arrived and since then my screen has cyan blue lines everywhere in all applications

bp-979e53e8-0a0d-4d79-adfd-d08212120508
Crashed after failing to UN-delete a message, and then trying to delete a message.
(Reporter)

Comment 1

5 years ago
perhaps top 50 crash, with combined Mac and windows crashes.
and amongst crashes caused by maillnews code, probably top 25

bp-5126ff70-4875-469b-bed4-626cf2121017 TB16 user frequently crashes (but no email address provided)

bp-7aaca7af-5aa7-44bb-bee5-c60662121017 TB18a2
0	xul.dll	nsMsgDBFolder::NotifyPropertyFlagChanged	mailnews/base/util/nsMsgDBFolder.cpp:4951
1	xul.dll	nsMsgDBFolder::SendFlagNotifications	mailnews/base/util/nsMsgDBFolder.cpp:697
2	xul.dll	nsMsgDBFolder::OnHdrFlagsChanged	mailnews/base/util/nsMsgDBFolder.cpp:1008
3	xul.dll	nsMsgDatabase::NotifyHdrChangeAll	mailnews/db/msgdb/src/nsMsgDatabase.cpp:837
4	xul.dll	nsMsgDatabase::MarkHdrReadInDB	mailnews/db/msgdb/src/nsMsgDatabase.cpp:2134
5	xul.dll	nsMsgDatabase::MarkHdrRead	mailnews/db/msgdb/src/nsMsgDatabase.cpp:2574
6	xul.dll	nsMsgDatabase::MarkRead	mailnews/db/msgdb/src/nsMsgDatabase.cpp:2147
7	xul.dll	nsMsgHdr::MarkRead	mailnews/db/msgdb/src/nsMsgHdr.cpp:228
8	xul.dll	nsMsgDBFolder::MarkMessagesRead	mailnews/base/util/nsMsgDBFolder.cpp:4689
9	xul.dll	nsMsgLocalMailFolder::MarkMessagesRead	mailnews/local/src/nsLocalMailFolder.cpp:1259
Crash Signature: [@ nsMsgDBFolder::NotifyPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int)] → [@ nsMsgDBFolder::NotifyPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int)] [@ nsMsgDBFolder::NotifyPropertyFlagChanged]
Keywords: regressionwindow-wanted
Whiteboard: [regression:v12] → [regression:TB12]
(Reporter)

Comment 2

5 years ago
#8 crash for Macs - for some reason the bug# isn't showing in crash-stats
Crash Signature: [@ nsMsgDBFolder::NotifyPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int)] [@ nsMsgDBFolder::NotifyPropertyFlagChanged] → [@ nsMsgDBFolder::NotifyPropertyFlagChanged] [@ nsMsgDBFolder::NotifyPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int)]
Flags: needinfo?(m_kato)
Keywords: qawanted

Comment 3

5 years ago
Crashing code:


4945 NS_OBSERVER_ARRAY_NOTIFY_OBSERVERS(mListeners, nsIFolderListener,
4946   OnItemPropertyFlagChanged,
4947   (aItem, aProperty, aOldValue, aNewValue));


The only way forward that I can see with this bug is to replace NS_OBSERVER_ARRAY_NOTIFY_OBSERVERS with a local custom version that checks for null entries.
Crash reason isn't null access, so this doesn't resolve by null checking.
Flags: needinfo?(m_kato)

Comment 5

5 years ago
(In reply to Makoto Kato from comment #4)
> Crash reason isn't null access, so this doesn't resolve by null checking.

How can you tell that?
(In reply to Kent James (:rkent) from comment #5)
> (In reply to Makoto Kato from comment #4)
> > Crash reason isn't null access, so this doesn't resolve by null checking.
> 
> How can you tell that?

If object is null, this crash address will be offset of virtual table.  But crash address seems to be random.

I think,

- notify observer (binary addon? or 3rd party DLL?) corrupts stack, then crash this.

or

- mListeners has invalid entry that isn't null.
(Reporter)

Comment 7

5 years ago
@0x0 | nsMsgDBFolder::NotifyPropertyFlagChanged 
bp-ed0f178b-f9e2-44e2-8af1-b281a2130912
Crash Signature: [@ nsMsgDBFolder::NotifyPropertyFlagChanged] [@ nsMsgDBFolder::NotifyPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int)] → [@ @0x0 | nsMsgDBFolder::NotifyPropertyFlagChanged ] [@ nsMsgDBFolder::NotifyPropertyFlagChanged] [@ nsMsgDBFolder::NotifyPropertyFlagChanged(nsIMsgDBHdr*, nsIAtom*, unsigned int, unsigned int)]
Keywords: qawanted
OS: Windows NT → All
Summary: crash in nsMsgDBFolder::NotifyPropertyFlagChanged → crash in nsMsgDBFolder::NotifyPropertyFlagChanged deleting or moving messages
(Reporter)

Comment 8

3 years ago
Neil, anything you can add to comment 6?
Flags: needinfo?(neil)
Keywords: topcrash-thunderbird

Comment 9

3 years ago
Are there any recent crashes?
As I understand it we only use that listener array in three cases:
1. The RDF data source (still used in SeaMonkey)
2. The Windows notification icon
3. Send in Background

They are all long-lived components and so are unlikely to be invalid.

Note: the mail session has a similar-sounding listener but this is invoked directly rather than registering itself as a listener on the folder.
Flags: needinfo?(neil)
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
(Reporter)

Comment 13

2 years ago
version 45.2.0 with 192 crashs per week = not even in top 50. So no longer topcrash
https://crash-stats.mozilla.com/signature/?signature=nsMsgDBFolder%3A%3ANotifyPropertyFlagChanged
Keywords: topcrash-thunderbird
(Reporter)

Comment 14

a year ago
crashed while attempting to reproduce bug Bug 860741 bp-dad5b307-8398-4eb2-b6ec-638a92170218 

(turns out TB was using 1.3GB memory before I crashed - unclear whether that is related) Not exact steps, but roughly - was after deleting a message in pop account, moving 3 from pop to imap, unsuccessful attempt undeleting, then trying to move 3 more messages

bug 587114 and bug 804662 appear to be related
Blocks: 587114, 804662
(Reporter)

Comment 15

7 months ago
mac crash addresses are all 0x0
of 240 crashes
* 50 are 0x25
*~20 are 0x646c6f8a
*~120 are  0xffffffffe5e5e609 

the rest of the addresses are relatively random
Summary: crash in nsMsgDBFolder::NotifyPropertyFlagChanged deleting or moving messages → crash in nsMsgDBFolder::NotifyPropertyFlagChanged deleting or moving messages, with (mostly) random addresses
You need to log in before you can comment on or make changes to this bug.