[faceted search] results list crash [@ nsMsgDBView::MarkThreadRead(nsIMsgThread*, unsigned int, nsTArray<unsigned int>&, int)]
3.0b4 top 20 crash, but not comment in nightlies. doesn't appear to go back far - the earliest I find is 20090627031459 build. Several mentioned doing "r" reply while in results list. marking blocking? because of it's potential to become topcrash with more search results usage.
xref Bug 522327 - crash clicking Go Back in search results [@ nsMsgDBView::NavigateFromPos(int, unsigned int, unsigned int*, unsigned int*, unsigned int*, int)]
More variety of crash comments...
* in search results as list, trying to mark a bunch of items as read. This was using an imap account.
* I was highlighting in the body of a message and attempted to type. The message was only available for viewing, not editing.
* I changed the listing in the search view to "list" and then selected all messages. Then, I hit the 'm' key to mark them all read and boom goes the email client.
* double clicking on it from the results.
most of the crashes (but not this one) are 0x0
thunderbird-bin nsMsgDBView::MarkThreadRead mailnews/base/src/nsMsgDBView.cpp:5909
1 thunderbird-bin nsMsgDBView::MarkThreadOfMsgRead mailnews/base/src/nsMsgDBView.cpp:5885
2 thunderbird-bin nsMsgDBView::SetThreadOfMsgReadByIndex mailnews/base/src/nsMsgDBView.cpp:3067
3 thunderbird-bin nsMsgDBView::ApplyCommandToIndices mailnews/base/src/nsMsgDBView.cpp:2745
4 thunderbird-bin nsMsgSearchDBView::DoCommand mailnews/base/src/nsMsgSearchDBView.cpp:816
5 libxpcom_core.dylib NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
6 thunderbird-bin XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2454
7 thunderbird-bin XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1590
taking, easy to reproduce
Created attachment 407396 [details] [diff] [review]
This makes us get the db from the msg hdr, instead of assuming the view has it. I found a few other places that were doing this and made them use a utility routine. I also looked for other commands that might have this same issue and didn't find any.
This should probably be added to some test case somewhere - I'll try to find an appropriate one...
fix on trunk and branch (I got the comment somewhat wrong in the trunk checkin, but with the right bug #)
v.fixed per crash stats, only crashes appearing are 3.0b4