Closed Bug 460036 Opened 16 years ago Closed 15 years ago

crash clicking on newsgroup [@ msvcr80.dll] [@ memmove - nsTArray_base::ShiftData ]

Categories

(Thunderbird :: Mail Window Front End, defect, P3)

x86
Windows Vista
defect

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b3

People

(Reporter: wsmwk, Assigned: rain1)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(2 files, 1 obsolete file)

crashed 3.0a3 twice clicking on mozilla.support.thunderbird newsgroup  [@ msvcr80.dll] [@ nsTArray_base::ShiftData] on the day of 3.0a3 announcement.
Not repeated since.  Unsure if news or front end

There are other nsTArray_base::ShiftData crashes - http://tinyurl.com/4yn8ls - but don't think any of those stacks are the same.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3

bp-f1d8bc5c-99ee-11dd-966e-001a4bd43e5c
and (same stack)
bp-c07717cf-99ee-11dd-bd93-001cc45a2ce4
0  	msvcr80.dll  	msvcr80.dll@0x1537a  	
1 	xpcom_core.dll 	nsTArray_base::ShiftData 	nsTArray.cpp:173
2 	thunderbird.exe 	nsTArray<nsIFormControl*>::ReplaceElementsAt<nsIFormControl*> 	nsTArray.h:494
3 	thunderbird.exe 	nsMsgThreadedDBView::OnNewHeader 	nsMsgThreadedDBView.cpp:647
4 	thunderbird.exe 	nsMsgDBView::OnHdrAdded 	nsMsgDBView.cpp:5126
5 	thunderbird.exe 	nsMsgDatabase::NotifyHdrAddedAll 	nsMsgDatabase.cpp:641
6 	thunderbird.exe 	nsMsgDatabase::AddNewHdrToDB 	nsMsgDatabase.cpp:3043
7 	thunderbird.exe 	nsNNTPNewsgroupList::CallFilters 	nsNNTPNewsgroupList.cpp:1137
8 	thunderbird.exe 	nsNNTPProtocol::ProcessXover 	nsNNTPProtocol.cpp:3543
9 	thunderbird.exe 	nsNNTPProtocol::ProcessProtocolState 	nsNNTPProtocol.cpp:5110
10 	thunderbird.exe 	thunderbird.exe@0x93fb17
Summary: crash clicking on newsgroup [@ msvcr80.dll] [@ nsTArray_base::ShiftData] → crash clicking on newsgroup [@ msvcr80.dll] [@ memmove - nsTArray_base::ShiftData ]
Well, the call to nsTArray::ReplaceElementsAt is simply what the inline call to m_keys.InsertElementAt(insertIndex, newKey); expands to.

insertIndex is either threadIndex (if this header is the new root of an existing thread) or the return value of GetInsertIndexForNewHdr, which itself is bounded by the view size and the return value of FindParentInThread, which itself is the index if the parent, or threadIndex if that isn't found. And threadIndex is always an existing index too, so I can't see how that call can fail either.
I just had a big batch of crashes trying to navigate news by using the 'n' key.

Breakpad has this Top Crasher with 26 reports
Crash Reports in msvcr80.dll@0x14500

Looks like it hit all Windows builds for 20081015
If the news message is down in a thread, then it opens fine (always). If it is the thread parent or a lone message, then clicking on it or opening in a new window crashes Thunderbird (almost always).

This started after applying the nightly build on the morning of 10/15/08, and continues with the current build.

Add-ons: {972ce4c6-7e08-4474-a285-3208198ce6fd}:2.0
BuildID: 20081015031353
CrashTime: 1224158612
Email: Brad@Lanier.ws
InstallTime: 1224074043
ProductName: Thunderbird
SecondsSinceLastCrash: 1447
StartupTime: 1224157687
Theme: classic/1.0
URL: 
UserID: e23db753-6db9-4274-9c42-8f45395c7140
Vendor: 
Version: 3.0b1pre
Keywords: topcrash
This has cleared up with install of
[App]
Name=Thunderbird
Version=3.0b1pre
BuildID=20081016152422
Copyright=Copyright (c) 1998-2008 mozilla.org
ID={3550f703-e582-4d05-9a08-453d09bdfdc6}

So either a patch landed or was backed out that was triggering this bug.
the only build with high # crashes is 2008101500. But started at least as early as 20081006. I'll have to upgrade and face the cut paste bug.
bad news - still fails for me 20081021032921 bp-b357d5fa-9fd2-11dd-8537-001a4bd43ed6
Keywords: regression
as a topcrash regression, this should be targeted for getting fixed in b1 or b2

a solution may also resolve 
bug 458868
bug 465011
Flags: blocking-thunderbird3?
i had just seen this bp-92b908fb-4749-4b71-83ee-b5e220081117
I can reliably reproduce this (and only) for a thread on which I did a subthread kill, "K".  And I can't reproduce it with other threads.  If I turn on View ignored, and collapse/expand the thread it does not crash.  So #suspect is bug 11054 which implemented kill subthread    2008-07-08

(Perhaps a coincidence, but I also replied to part of the thread which I had not killed.)
Blocks: JTK
#3 crash msvcr80.dll@0x1537, nsTArray_base::ShiftData

all builds
http://crash-stats.mozilla.com/report/list?product=Thunderbird&version=Thunderbird%3A3.0b1&version=Thunderbird%3A3.0b1pre&version=Thunderbird%3A3.0b2pre&query_search=stack&query_type=contains&query=nsTArray_base%3A%3AShiftData&date=&range_value=1&range_unit=weeks&do_query=1&signature=msvcr80.dll%400x1537a

just seen - same line # - nsTArray.cpp:173 - but different stack

bp-5804e37c-0069-4bb7-bc3d-8bdf22081228
msvcr80.dll@0x1537a	
nsTArray_base::ShiftData	nsTArray.cpp:173
nsMsgDBView::RemoveRows	nsMsgDBView.cpp:4866
nsMsgDBView::CollapseByIndex	nsMsgDBView.cpp:4443
nsMsgThreadedDBView::MoveThreadAt	nsMsgThreadedDBView.cpp:786
nsMsgThreadedDBView::OnNewHeader	nsMsgThreadedDBView.cpp:675
nsMsgDBView::OnHdrAdded	nsMsgDBView.cpp:5316
nsMsgDatabase::NotifyHdrAddedAll	nsMsgDatabase.cpp:683
nsMsgDatabase::AddNewHdrToDB	nsMsgDatabase.cpp:3043
nsImapMailDatabase::AddNewHdrToDB	nsImapMailDatabase.cpp:156
nsImapMailFolder::NormalEndHeaderParseStream	nsImapMailFolder.cpp:2925
nsImapMailFolder::ParseMsgHdrs	nsImapMailFolder.cpp:2760
NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
nsEventQueue::GetEvent	xpcom/threads/nsEventQueue.cpp:100
nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:181
nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:510
msvcr80.dll@0x1537a occurs on 3.0a2. not found in 3.0a2pre, 3.0a1pre nor 3.0a1 (but could easily not be enough users of those releases for the crash to occur)

happens also with cross/multiple folder search
bp-121539f6-eaad-4446-aeb3-68c662090121
msvcr80.dll@0x1537a	
nsTArray_base::ShiftData	nsTArray.cpp:173
nsTArray<nsDisplayItem*>::ReplaceElementsAt<nsDisplayItem*>	nsTArray.h:494
nsMsgSearchDBView::InsertMsgHdrAt	nsMsgSearchDBView.cpp:300
nsMsgSearchDBView::AddHdrFromFolder	nsMsgSearchDBView.cpp:450
nsMsgXFVirtualFolderDBView::OnSearchHit	nsMsgXFVirtualFolderDBView.cpp:316
nsMsgXFVirtualFolderDBView::OnNewHeader	nsMsgXFVirtualFolderDBView.cpp:150
nsMsgDBView::OnHdrAdded	nsMsgDBView.cpp:5318
nsMsgDatabase::NotifyHdrAddedAll	nsMsgDatabase.cpp:683
nsMsgDatabase::AddNewHdrToDB	nsMsgDatabase.cpp:3043
based on component, assigning to bienvenu for further triage.  accepting blocking based on topcrash.
Assignee: nobody → bienvenu
Flags: blocking-thunderbird3? → blocking-thunderbird3+
I can fix the MoveThreadAt case, so putting in b2. I can't reproduce it, but I've seen it a couple times.
Target Milestone: --- → Thunderbird 3.0b2
Attached patch possible fixSplinter Review
this should fix the crash - I still need to figure out what's causing the underlying problem, but it would be nice to land this and see if it makes this stack disappear from the top crashes.
Attachment #358082 - Flags: superreview?(bugzilla)
Attachment #358082 - Flags: review?(bugzilla)
Comment on attachment 358082 [details] [diff] [review]
possible fix

Yeah, lets give this a try.
Attachment #358082 - Flags: superreview?(bugzilla)
Attachment #358082 - Flags: superreview+
Attachment #358082 - Flags: review?(bugzilla)
Attachment #358082 - Flags: review+
fix checked in.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This still exists in 3.0b3pre - bp-e636735b-f9d6-4043-8e94-bb3cd2090317

And a variation that includes nsMsgQuickSearchDBView
bp-4bb5ace6-956e-4c4c-b329-2ff8b2090317
0	mozcrt19.dll	memmove	MEMCPY.ASM:188
1	xpcom_core.dll	nsTArray_base::ShiftData	nsTArray.cpp:173
2	thunderbird.exe	nsTArray<nsDisplayItem*>::ReplaceElementsAt<nsDisplayItem*>	nsTArray.h:494
3	thunderbird.exe	nsMsgDBView::InsertMsgHdrAt	nsMsgDBView.cpp:1502
4	thunderbird.exe	nsMsgThreadedDBView::OnNewHeader	nsMsgThreadedDBView.cpp:654
5	thunderbird.exe	nsMsgQuickSearchDBView::OnNewHeader	nsMsgQuickSearchDBView.cpp:160
6	thunderbird.exe	nsMsgDBView::OnHdrAdded	nsMsgDBView.cpp:5348
7	thunderbird.exe	nsMsgDatabase::NotifyHdrAddedAll	nsMsgDatabase.cpp:682
8	thunderbird.exe	nsMsgDatabase::AddNewHdrToDB	nsMsgDatabase.cpp:3035
9	thunderbird.exe	nsImapMailDatabase::AddNewHdrToDB	nsImapMailDatabase.cpp:156
10	thunderbird.exe	nsImapMailFolder::NormalEndHeaderParseStream	nsImapMailFolder.cpp:2914
11	thunderbird.exe	nsImapMailFolder::ParseMsgHdrs	nsImapMailFolder.cpp:2749
12	xpcom_core.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Is this still happening in 3.0b3 pre?
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b3
not many instances of this crash in crash-stats. But it should be fairly easy to fix.
Priority: -- → P3
sid, interested in tackling this? My guess is that we're trying to insert at index -1 - AddHdrFromFolder is probably getting -1 for the index to insert at.
So bp-4bb5ace6-956e-4c4c-b329-2ff8b2090317 indicates that nsMsgThreadedDBView::OnNewHeader line 654 <http://hg.mozilla.org/comm-central/annotate/d9fef5145cba/mailnews/base/src/nsMsgThreadedDBView.cpp#l654> is what's causing trouble, but insertIndex can't be -1 there. insertIndex is greater than the length of the array, and that's what's actually causing trouble.

This is an attempt to paper over the trouble and hopefully not crash. This is far from a fix, though.
Assignee: bienvenu → sid.bugzilla
Status: REOPENED → ASSIGNED
Attachment #375855 - Flags: superreview?(bienvenu)
Attachment #375855 - Flags: review?(bienvenu)
Comment on attachment 375855 [details] [diff] [review]
paper over issue, but fire an assertion as well

nsMsgViewIndex is of type unsigned, so you'd need to cast it to a signed int32 first for that check to be meaningful. Also, should use NS_ERROR( instead of NS_ASSERTION(PR_FALSE,

r/sr=me, with those fixed. I think it's worthwhile add this check to see if we can tell if it stops the crash.
Attachment #375855 - Flags: superreview?(bienvenu)
Attachment #375855 - Flags: superreview+
Attachment #375855 - Flags: review?(bienvenu)
Attachment #375855 - Flags: review+
Attachment #375855 - Attachment is obsolete: true
Attachment #375952 - Flags: superreview+
Attachment #375952 - Flags: review+
Keywords: checkin-needed
Checked in: http://hg.mozilla.org/comm-central/rev/00c8a1796b2a
Status: ASSIGNED → RESOLVED
Closed: 15 years ago15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Thanks sid.

I can't reproduce with 20090505, build immediately prior to patch. So I'm not even going to try with the patch. If no one else has steps then must rely on 3.0b3pre or 3.0b3 crash-stats to verify this is fixed, and it will be a couple weeks before we know.  Benchmark for 3.0b3pre is 6 memmove crashes in last 2 weeks with nsTArray_base::ShiftData in the stack per below:

2009-05-04 15:06  	Thunderbird	3.0b3pre	20090426031511
2009-04-28 21:41 	Thunderbird	3.0b3pre	20090417032333
2009-04-23 21:45 	Thunderbird	3.0b3pre	20090414033952
2009-04-23 21:44 	Thunderbird	3.0b3pre	20090414033952
2009-04-23 21:44 	Thunderbird	3.0b3pre	20090414033952
2009-04-22 10:33 	Thunderbird	3.0b3pre	20090411032110

and one top of stack nsTArray_base::ShiftData bp-9b92f935-ba83-4013-b2b4-fddf12090427

to be clear, still a toprcrash for 3.0b3
Crash Signature: [@ msvcr80.dll] [@ memmove - nsTArray_base::ShiftData ]
You need to log in before you can comment on or make changes to this bug.