[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 bp-c4e819b4-f889-4d47-b062-ccb582091013 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] proposed fix 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