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

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

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

as a topcrash regression, this should be targeted for getting fixed in b1 or b2 a solution may also resolve bug 458868 bug 465011

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

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

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

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 on attachment 358082 [details] [diff] [review] possible fix Yeah, lets give this a try.

fix checked in.

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

Is this still happening in 3.0b3 pre?

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

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.

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.

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

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