Closed Bug 524673 Opened 15 years ago Closed 15 years ago

crash [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)]

Categories

(MailNews Core :: Backend, defect)

1.9.1 Branch
x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.0rc1

People

(Reporter: Usul, Assigned: Bienvenu)

References

()

Details

(Keywords: crash, fixed-seamonkey2.0.1)

Crash Data

Attachments

(1 file)

STR:

1. TB safe-mode and view "All Folder";
2. select a folder (e.g. I select my bugzilla folder on Local Folders);
3. on context menu of this folder select "Search";
4. fill one criteria (in my case I create a new "custom headers"
X-Bugzilla-Status and set is as RESOLVED);
5. click on search button on search window;
6. on results section click to "select column to display" and add "Thread";
7. on result section click on Thread column for sort by Thread: TB crash.
This crash has to do very specifically with adding the thread colun to the search window and then clicking on the thread column - we try to do a sort by an invalid column, and things spiral out of control a bit.
Attached patch proposed fixSplinter Review
this patch does two things:

move OpenWithHdrs to nsMsgSearchDBView from nsMsgXFVirtualFolderDBView, so that switching to threaded mode doesn't turn on the grouping flag, which nsMsgGroupView does - basically, nsMsgSearchDBView needs to override OpenWithHdrs just like nsMsgXFVirtualFolderDBView did, and since nsMsgXFVirtualFolderDBView inherits from nsMsgSearchDBView, moving the override is the right thing to do.

Make sure we're not sorted byNone if threading is turned on in search views - it leads to the errors I described earlier.
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
Attachment #408773 - Flags: superreview?(bugzilla)
Attachment #408773 - Flags: review?(bugzilla)
pinging for r/sr - this fixes an easy to reproduce crash...
Attachment #408773 - Flags: superreview?(bugzilla)
Attachment #408773 - Flags: superreview+
Attachment #408773 - Flags: review?(bugzilla)
Attachment #408773 - Flags: review+
Attachment #408773 - Flags: approval-thunderbird3+
fix pushed for 3.0 rc1 and trunk.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0rc1
crash is not seen in v3.0.0 (but is in 3.0b4) so I would say this crash is
indeed gone
Status: RESOLVED → VERIFIED
Ludo, was nsMsgXFVirtualFolderDBView  the second frame on the stack for this crash?

There are several crash signatures whose stacks contain nsMsgXFVirtualFolderDBView http://crash-stats.mozilla.com/query/query?product=Thunderbird&version=ALL%3AALL&date=&range_value=2&range_unit=days&query_search=stack&query_type=contains&query=nsMsgXFVirtualFolderDBView+&build_id=&process_type=all&do_query=1 - but without investing a lot more time I don't know that any of these are regressions or in any way connected.

 memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)  bp-7a5c0163-64b5-4027-95a5-4c4452100329
nsMsgXFVirtualFolderDBView::CopyDBView(nsMsgDBView*, nsIMessenger*, nsIMsgWindow*, nsIMsgDBViewCommandUpdater*) bp-4195ffc4-228e-44ae-99f5-e28192100329
nsMsgXFViewThread::AddHdr(nsIMsgDBHdr*, int, unsigned int&, nsIMsgDBHdr**)
nsMsgDBView::FnSortIdKeyPtr(void const*, void const*, void*)
nsMsgDatabase::GetSearchResultsTable(char const*, int, nsIMdbTable**)
arena_dalloc_small | arena_dalloc | free | nsMsgHdr::`vector deleting destructor''(unsigned int)
Yes
I can't find ludo's crash** with  nsMsgXFVirtualFolderDBView on the stack so I'm hesitant about adding  - [@ nsMsgXFVirtualFolderDBView] to the summary

** http://crash-stats.mozilla.com/query/query?product=Thunderbird&version=ALL%3AALL&date=10%2F28%2F2009&range_value=2&range_unit=days&query_search=stack&query_type=contains&query=nsMsgXFVirtualFolderDBView&build_id=&process_type=all&do_query=1 yields only two crashes bp-31914940-f80f-4a9e-a465-262e52091026 and a eudora crash. And I can't find the crash by time of day because of bug 555740 - [socorro] filter time spec doesn't work with date - means
Summary: crash [@memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) ] → crash [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)]
Crash Signature: [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: