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

Status: RESOLVED FIXED

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

Description

[Wayne Mery (:wsmwk)]

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

Comment 1

[[e-mail]]

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.

Comment 2

[Ronald Killmer]

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

Comment 3

[Brad Lanier]

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: [e-mail]
InstallTime: 1224074043
ProductName: Thunderbird
SecondsSinceLastCrash: 1447
StartupTime: 1224157687
Theme: classic/1.0
URL: 
UserID: e23db753-6db9-4274-9c42-8f45395c7140
Vendor: 
Version: 3.0b1pre

Comment 4

[Ronald Killmer]

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.

Comment 5

[Wayne Mery (:wsmwk)]

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.

Comment 6

[Wayne Mery (:wsmwk)]

bad news - still fails for me 20081021032921 bp-b357d5fa-9fd2-11dd-8537-001a4bd43ed6

Comment 7

[Wayne Mery (:wsmwk)]

as a topcrash regression, this should be targeted for getting fixed in b1 or b2

a solution may also resolve 
bug 458868
bug 465011

Comment 8

[Wayne Mery (:wsmwk)]

i had just seen this bp-92b908fb-4749-4b71-83ee-b5e220081117

Comment 9

[Wayne Mery (:wsmwk)]

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.)

Comment 10

[Wayne Mery (:wsmwk)]

#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

Comment 12

[Wayne Mery (:wsmwk)]

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

Comment 13

[David Ascher (:davida)]

based on component, assigning to bienvenu for further triage.  accepting blocking based on topcrash.

Comment 14

[David :Bienvenu]

I can fix the MoveThreadAt case, so putting in b2. I can't reproduce it, but I've seen it a couple times.

Comment 15

[David :Bienvenu]

Attachment: possible fix

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.

Comment 16

[Mark Banner (:standard8)]

Comment on attachment 358082 [details] [diff] [review]
possible fix

Yeah, lets give this a try.

Comment 17

[David :Bienvenu]

fix checked in.

Comment 18

[Wayne Mery (:wsmwk)]

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

Comment 19

[David :Bienvenu]

Is this still happening in 3.0b3 pre?

Comment 20

[David :Bienvenu]

not many instances of this crash in crash-stats. But it should be fairly easy to fix.

Comment 21

[David :Bienvenu]

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.

Comment 22

[Rain [:rain1] (inactive)]

Attachment: paper over issue, but fire an assertion as well

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.

Comment 23

[David :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.

Comment 24

[Rain [:rain1] (inactive)]

Attachment: updated patch, addressing review comments

Comment 25

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/00c8a1796b2a

Comment 26

[Wayne Mery (:wsmwk)]

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