Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in Thunderbird 3.0rc1

Status

MailNews Core
Backend
--
critical
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: Usul, Assigned: Bienvenu)

Tracking

({crash, fixed-seamonkey2.0.1, topcrash})

1.9.1 Branch
Thunderbird 3.0rc1
x86
Windows XP
crash, fixed-seamonkey2.0.1, topcrash
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact][ccbr], crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
STR from bug https://bugzilla.mozilla.org/show_bug.cgi?id=518128#c8:
1. start TB in safe-mode;
2. go to view "All Folders"
3. create a saved search (I create a saved search base on my TBbugzilla with
fiter condition <subject> <contains> <bug>: all 2019 mails are selected);
4. sort saved search group by sort (date descending) and fill "bug." (without
quotes) on globalsearch when is applied "search all messages" and don't raise
search;
5. change filter on globalsearch to "Subject or From" (zero results);
6. in message pane click on "+\-" icon (one or two time): crash!
Flags: blocking-thunderbird3?
memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)

#13 in 3.0b4 [1] and #18 for 3.0pre. Hopefully blocking is justified by an easy fix, given we have good STR thanks to Aureliano. But given the 3.0pre crash rate we may not know for ~6 days from patch landing whether this significantly affects crash profile.

Optimistically marking topcrash, but I  haven't examined the stacks of [1] ... there may be multiple stacks/causes of this top of stack [2].  (most of our crashes mention deleting or clicking on messages, not manipulating filters, threads, etc)

from bug 518128, bp-044bb85b-072f-47ff-aa2d-b8df92091022
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	nsMsgDBView::RemoveRows	mailnews/base/src/nsMsgDBView.cpp:5193
3	thunderbird.exe	nsMsgDBView::CollapseByIndex	mailnews/base/src/nsMsgDBView.cpp:4768
4	thunderbird.exe	nsMsgDBView::ToggleExpansion	mailnews/base/src/nsMsgDBView.cpp:4598
5	thunderbird.exe	nsMsgDBView::ToggleOpenState	mailnews/base/src/nsMsgDBView.cpp:1934
6	xpcom_core.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101 

[1] http://crash-stats.mozilla.com/report/list?product=Thunderbird&version=Thunderbird%3A3.0b4&query_search=signature&query_type=contains&query=&date=&range_value=4&range_unit=weeks&do_query=1&signature=memmove%20|%20nsTArray_base%3A%3AShiftData%28unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20int%2C%20unsigned%20int%29

[2] xref [INVALID] Bug 519771 -  Crash [@memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) ]
Component: General → Backend
Keywords: topcrash
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Whiteboard: [ccbr]
Version: 3.0 → 1.9.1 Branch
(Assignee)

Comment 2

8 years ago
taking, I can reproduce this.
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
Flags: blocking-thunderbird3? → blocking-thunderbird3+
(Assignee)

Comment 3

8 years ago
The steps are a little simpler:

1. create a saved search (I create a saved search base on my TBbugzilla with
fiter condition <subject> <contains> <bug>: all 2019 mails are selected);
2. sort saved search group by sort (date descending)
search;
3. Do a "Subject or From" search on "bug." (which shouldn't get hits)
4. in message pane click on "+\-" icon (one or two time): crash!

After 3, we end up with the groups looking expanded in the sense that the triangle is open, but there aren't any rows displayed. And the counts on the group are completely wrong, as if we haven't cleared out the group correctly.
(Assignee)

Comment 4

8 years ago
OK, the issue removing cached hits on saved searches that are no longer matches doesn't update the groups correctly - we call RemoveByIndex, but that doesn't update the groups correctly. We need to do something more like OnHdrDeleted, which has all the smarts for updating the groups.
(Assignee)

Comment 5

8 years ago
Created attachment 408134 [details] [diff] [review]
proposed fix

this fixes it for me, and mirrors what we're doing in the cross-folder view case. There are things going wrong upstream in the sense that the quick search on the saved search is getting initialized with the saved search results, when it really shouldn't be, and that's why we have to clear out all the stale hits. But the stale hit clearing out code needs to go through the OnHdrDeleted path.
Attachment #408134 - Flags: superreview?(bugzilla)
Attachment #408134 - Flags: review?(bugzilla)
(Assignee)

Comment 6

8 years ago
I'll try to come up with an xpcshell or mozmill test for this.
Whiteboard: [ccbr] → [ccbr][has patch for r/sr standard8]

Updated

8 years ago
Whiteboard: [ccbr][has patch for r/sr standard8] → [no l10n impact][ccbr][has patch for r/sr standard8]
Comment on attachment 408134 [details] [diff] [review]
proposed fix

I've not been able to reproduce the crash with or without this (except for one with a cross folder search that I told bienvenu about earlier).

However the changes look fine, r/sr=Standard8
Attachment #408134 - Flags: superreview?(bugzilla)
Attachment #408134 - Flags: superreview+
Attachment #408134 - Flags: review?(bugzilla)
Attachment #408134 - Flags: review+
Whiteboard: [no l10n impact][ccbr][has patch for r/sr standard8] → [no l10n impact][ccbr][read
Whiteboard: [no l10n impact][ccbr][read → [no l10n impact][ccbr][ready to land when tree opens]
(Assignee)

Comment 8

8 years ago
fixed on 3.0 branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][ccbr][ready to land when tree opens] → [no l10n impact][ccbr]
Target Milestone: --- → Thunderbird 3.0rc1
Reading today pushlog it seems that the fix is landed, but I can reproduce this crash (with different STR) using today nyghtly build.
I forgot:

http://crash-stats.mozilla.com/report/index/bp-b006c009-1f7e-4ea2-82af-5072a2091027

http://crash-stats.mozilla.com/report/index/bp-1038d104-17f9-477b-8a28-fcfa32091027
(Reporter)

Comment 11

8 years ago
What are the new STRs ?
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.
Whilst it ends up crashing in the same place, it is a different bug because its different STR and a different stack leading up to the crash.
(Reporter)

Comment 14

8 years ago
/me opens a new bug

Updated

8 years ago
Keywords: fixed-seamonkey2.0.1
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)] - [@ nsMsgDBView::RemoveRows]
Crash Signature: [@memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)] [@ nsMsgDBView::RemoveRows]
You need to log in before you can comment on or make changes to this bug.