Closed Bug 596567 Opened 15 years ago Closed 14 years ago

crash [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)] - [@ nsMsgSearchDBView::InsertMsgHdrAt], [@ nsMsgSearchDBView::InsertMsgHdrAt(unsigned int, nsIMsgDBHdr*, unsigned int, unsigned int, unsigned int)] (Mac)

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(thunderbird5.0 beta2-fixed, thunderbird6 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 7.0
Tracking Flags:
Tracking Status
thunderbird5.0 --- beta2-fixed
thunderbird6 --- fixed

People

(Reporter: wsmwk, Assigned: Bienvenu)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [gs])

Crash Data

Attachments

(1 file)

array index validation check
1.01 KB, patch
standard8
: review+
standard8
: approval-comm-aurora+
standard8
: approval-thunderbird5.0+
Details | Diff | Splinter Review
crash [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)] - [@ nsMsgSearchDBView::InsertMsgHdrAt] reporter in http://gsfn.us/t/1g213 indicates crashes happen in clusters "two or three crashes within minutes or maybe a 24 hour period, every couple of weeks" ... "believe the crashes occur while TB is processing new mail discovered when mail was checked (I use POP with SSL/TLS and have the client set to check for new mail every 2 minutes)." bp-430cff5d-31a2-4b33-a512-6ab652100909 0 mozcrt19.dll memmove MEMCPY.ASM:188 1 xpcom_core.dll nsTArray_base::ShiftData objdir-tb/mozilla/xpcom/build/nsTArray.cpp:173 2 thunderbird.exe nsTArray<nsDisplayItem*>::ReplaceElementsAt<nsDisplayItem*> objdir-tb/mozilla/dist/include/nsTArray.h:494 3 thunderbird.exe nsMsgSearchDBView::InsertMsgHdrAt mailnews/base/src/nsMsgSearchDBView.cpp:350 4 thunderbird.exe nsMsgSearchDBView::AddHdrFromFolder mailnews/base/src/nsMsgSearchDBView.cpp:504 5 thunderbird.exe nsMsgXFVirtualFolderDBView::OnSearchHit mailnews/base/src/nsMsgXFVirtualFolderDBView.cpp:313 6 thunderbird.exe nsMsgXFVirtualFolderDBView::OnNewHeader mailnews/base/src/nsMsgXFVirtualFolderDBView.cpp:162 7 thunderbird.exe nsMsgDBView::OnHdrAdded mailnews/base/src/nsMsgDBView.cpp:5697 8 thunderbird.exe nsMsgDatabase::NotifyHdrAddedAll mailnews/db/msgdb/src/nsMsgDatabase.cpp:736 9 thunderbird.exe nsMsgDatabase::AddNewHdrToDB mailnews/db/msgdb/src/nsMsgDatabase.cpp:3281 10 thunderbird.exe nsParseNewMailState::MoveIncorporatedMessage mailnews/local/src/nsParseMailbox.cpp:2545 11 thunderbird.exe nsParseNewMailState::ApplyFilterHit mailnews/local/src/nsParseMailbox.cpp:2060 12 thunderbird.exe nsMsgFilterList::ApplyFiltersToHdr mailnews/base/search/src/nsMsgFilterList.cpp:360 13 thunderbird.exe nsParseNewMailState::ApplyFilters mailnews/local/src/nsParseMailbox.cpp:1947 14 thunderbird.exe nsParseNewMailState::PublishMsgHeader mailnews/local/src/nsParseMailbox.cpp:1881 15 thunderbird.exe nsPop3Sink::IncorporateComplete mailnews/local/src/nsPop3Sink.cpp:953
reporter, using pop, thinks this may be related to filters.
URL: http://getsatisfaction.com/mozilla_me...
Mac crash bp-e2dcf672-e704-4f1c-8894-a17e72100913 has much of the same stack at the top, but no filter frame nsMsgSearchDBView::InsertMsgHdrAt(unsigned int, nsIMsgDBHdr*, unsigned int, unsigned int, unsigned int) 0 @0xffff0f14 1 thunderbird-bin nsMsgSearchDBView::InsertMsgHdrAt 2 thunderbird-bin nsMsgSearchDBView::AddHdrFromFolder mailnews/base/src/nsMsgSearchDBView.cpp:504 3 thunderbird-bin nsMsgXFVirtualFolderDBView::OnSearchHit mailnews/base/src/nsMsgXFVirtualFolderDBView.cpp:313 4 thunderbird-bin nsMsgXFVirtualFolderDBView::OnNewHeader mailnews/base/src/nsMsgXFVirtualFolderDBView.cpp:162 5 thunderbird-bin nsMsgDatabase::NotifyHdrAddedAll mailnews/db/msgdb/src/nsMsgDatabase.cpp:736 6 thunderbird-bin nsMsgDatabase::AddNewHdrToDB mailnews/db/msgdb/src/nsMsgDatabase.cpp:3281 7 thunderbird-bin nsPop3Sink::IncorporateComplete mailnews/local/src/nsPop3Sink.cpp:919 8 thunderbird-bin nsPop3Protocol::HandleLine mailnews/local/src/nsPop3Protocol.cpp:3547 9 thunderbird-bin nsPop3Protocol::RetrResponse mailnews/local/src/nsPop3Protocol.cpp:3333 10 thunderbird-bin nsPop3Protocol::ProcessProtocolState mailnews/local/src/nsPop3Protocol.cpp:3954 11 thunderbird-bin nsMsgProtocol::OnDataAvailable mailnews/base/util/nsMsgProtocol.cpp:359 12 thunderbird-bin nsInputStreamPump::OnStateTransfer netwerk/base/src/nsInputStreamPump.cpp:510
Timeless, bienvenu need more info? And, does it look related to filters?
3239 NS_IMETHODIMP nsMsgDatabase::AddNewHdrToDB(nsIMsgDBHdr *newHdr, PRBool notify) 3240 { 3241 nsMsgHdr* hdr = static_cast<nsMsgHdr*>(newHdr); // closed system, cast ok yeah, that's not scary... 3280 newHdr->GetThreadParent(&threadParent); 3281 NotifyHdrAddedAll(newHdr, threadParent, flags, NULL); Offhand, I'd probably try changing line 3241. I can't see anything else that's interesting. And this is really grasping at straws.
No, I think the straw to grasp at is an invalid insert index.
Mac version of this appears to be nsMsgSearchDBView::InsertMsgHdrAt(unsigned int, nsIMsgDBHdr*, unsigned int, unsigned int, unsigned int) bp-ebff9d6f-d159-4f4a-9b0a-eadc62110127 (mitra)
Summary: crash [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)] - [@ nsMsgSearchDBView::InsertMsgHdrAt] → unsigned int)] (Mac) crash [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)] - [@ nsMsgSearchDBView::InsertMsgHdrAt], [@ nsMsgSearchDBView::InsertMsgHdrAt(unsigned int, nsIMsgDBHdr*, unsigned int, unsigned int
I'm not using any filter and I get these crashes as well (many times a day, on Windows and Linux).
Benjamin Ryzman, please post one of your crash report IDs. Thanks see http://support.mozillamessaging.com/en-US/kb/Mozilla+Crash+Reporter#Viewing_crash_reports
FWIW I still get the crashes on a regular basis with version 3.1.10 on Windows
Crash Signature: [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)] [@ nsMsgSearchDBView::InsertMsgHdrAt] [@ nsMsgSearchDBView::InsertMsgHdrAt(unsigned int, nsIMsgDBHdr*, unsigned int, unsigned int, unsigned int)]
5.0b1 topcrash for 4-6 people, with a different signature [@ memmove | nsTArray_base<nsTArrayDefaultAllocator>::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) | nsTArray<mozilla::dom::PAudioParent*, nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int, unsigned int,mozilla::dom::PAudioParent* const*,unsigned int)] eg bp-0b21decd-1def-45b2-8db3-1e0272110614 0 mozcrt19.dll memmove MEMCPY.ASM:188 1 xul.dll nsTArray_base<nsTArrayDefaultAllocator>::ShiftData(unsigned int,unsigned int,unsigned int,unsigned int) objdir-tb/mozilla/dist/include/nsTArray-inl.h:180 2 xul.dll nsTArray<mozilla::dom::PAudioParent*,nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int,unsigned int,mozilla::dom::PAudioParent* const*,unsigned int) objdir-tb/mozilla/dist/include/nsTArray.h:632 3 xul.dll nsMsgSearchDBView::InsertMsgHdrAt(unsigned int,nsIMsgDBHdr*,unsigned int,unsigned int,unsigned int) mailnews/base/src/nsMsgSearchDBView.cpp:353 4 xul.dll nsMsgSearchDBView::AddHdrFromFolder(nsIMsgDBHdr*,nsIMsgFolder*) mailnews/base/src/nsMsgSearchDBView.cpp:507 5 xul.dll nsMsgXFVirtualFolderDBView::OnNewSearch() mailnews/base/src/nsMsgXFVirtualFolderDBView.cpp:475 6 xul.dll nsMsgSearchSession::Search(nsIMsgWindow*) mailnews/base/search/src/nsMsgSearchSession.cpp:283
Crash Signature: [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)] [@ nsMsgSearchDBView::InsertMsgHdrAt] [@ nsMsgSearchDBView::InsertMsgHdrAt(unsigned int, nsIMsgDBHdr*, unsigned int, unsigned int, unsigned int)] → nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int, unsigned int,mozilla::dom::PAudioParent* const*,unsigned int)] unsigned int)] [@ memmove | nsTArray_base<nsTArrayDefaultAllocator>::ShiftData(unsigned int, unsigne…
This fixed a persistent crash that JB was seeing in Miramar - he did see some odd things that eventually worked themselves out, and since this is only affects the view, it seems better than crashing.
Assignee: nobody → dbienvenu
Attachment #539793 - Flags: review?(mbanner)
Crash Signature: nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int, unsigned int,mozilla::dom::PAudioParent* const*,unsigned int)] → nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int, unsigned int,mozilla::dom::PAudioParent* const*,unsigned int) ]
Comment on attachment 539793 [details] [diff] [review] array index validation check I think this is worth taking on our active branches as well, as its been seen in TB 5.
Attachment #539793 - Flags: review?(mbanner)
Attachment #539793 - Flags: review+
Attachment #539793 - Flags: approval-thunderbird5.0+
Attachment #539793 - Flags: approval-comm-aurora+
Crash Signature: nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int, unsigned int,mozilla::dom::PAudioParent* const*,unsigned int) ] → unsigned int, unsigned int) | nsTArray<mozilla::dom::PAudioParent*, nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int, unsi ] nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::PAudioParent*>(unsigned int…
fixed on trunk and miramar: http://hg.mozilla.org/comm-central/rev/495ed5579693 http://hg.mozilla.org/releases/comm-miramar/rev/938a9a17342c will push to aurora once I've finished other stuff needed for 5.0 b2
Status: NEW → RESOLVED
Closed: 14 years ago
status-thunderbird5.0: --- → beta2-fixed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 7.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: