Using today's branch nightly on Windows. I was running 220.127.116.11 testing something out. Then I went back to Thunderbird 2, clicked on a saved search folder that spans multiple accounts and crashed. Restarting and I still crashed. Note: this sure does look a lot like Bug 352287 TB29181688 nsMsgQuickSearchDBView::OnSearchDone [mozilla/mailnews/base/src/nsMsgQuickSearchDBView.cpp, line 270] nsMsgSearchSession::NotifyListenersDone [mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp, line 608] nsMsgSearchSession::TimerCallback [mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp, line 540] nsTimerImpl::Fire [mozilla/xpcom/threads/nsTimerImpl.cpp, line 394]
if your saved search folder spans multiple accounts, why whould we be in nsMsgQuickSearchDBView::OnSearchDone? Were you in a view in the saved search folder?
Hmm, I could have sworn it used to span multiple folders (not multiple accounts). After running in a debug trunk build, I'm able to load the folder again without crashing and verified that it's just searching a single folder. I think something weird happened when I went back to 1.5 and then back to tb2. The first time I ran none of my virtual folders loaded, then the second time I ran, I got a bunch of saved search folders that I haven't seen in a long time. Then those disappeared after a couple crashes loading that one search. David, can you try running 1.5 and seeing if you notice anything weird the first time you run tb2 after that?
I run 1.5 quite a bit more than I'd like to :-) and I haven't seen this issue. But I really only have one saved search that I use regularly, which checks all my inboxes and filter targets for new mail. I know I've used that with 1.5, because I notice how slow it is compared to 2.0... anything special about the folders the saved search searched over? e.g., folder names that needed encoding? or the saved search itself?
Just seen this on TB18.104.22.168 on upgrading from TB22.214.171.124: http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=32884310 http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=32884789 This doesn't happen with a blank profile created in TB2.
To update, I have today installed TB2 on a different machine and, knowing about the problems I had yesterday, started with a blank profile. Same bug manifested itself, unfortunately: http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=32912807 http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=32912828
Ian, have you seen the crash since with newer v2?
Severity: normal → critical
I have now started seeing this issue. I used to have a search folder that did a basic search on "From:" and Tags contains. The search itself works fine, and the Search Folder is created. Clicking on the Folder however produces a crash. All other search folders seem to work ok, except for this one. And the name of it doesn't appear to be relevant. Tom
Created attachment 329256 [details] [diff] [review] proposed fix RefreshCache can fail at least via nsMsgDatabase::GetSearchResultsTable() and by OOM
Component: General → MailNews: Backend
OS: Windows XP → All
Priority: -- → P3
Product: Thunderbird → Core
QA Contact: general → backend
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1a1
Version: 2.0 → Trunk
Comment on attachment 329256 [details] [diff] [review] proposed fix I think OOM is the only realistic way it can fail, so I don't know that this patch is going to fix the problem. RefreshCache tells GetSearchResultsTable to create the table if it's missing and that generally succeeds, bar OOM. But, we should check for the error.
Checking in mailnews/base/src/nsMsgQuickSearchDBView.cpp; /cvsroot/mozilla/mailnews/base/src/nsMsgQuickSearchDBView.cpp,v <-- nsMsgQuickSearchDBView.cpp new revision: 1.37; previous revision: 1.36 done ->FIXED (hopefully, if it still crashes we can open a new bug for that)
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Created attachment 330627 [details] [diff] [review] proposed fix (1.8 branch) Just adding an rv check, should be very safe for branch too.
Attachment #330627 - Flags: approval126.96.36.199?
Any news on this? When will the fix be in a release version? This bug effectively renders the (great) 'Saved Search Folder' feature unusable for me.
Attachment #330627 - Flags: approval188.8.131.52? → approval184.108.40.206+
Magnus: stepping on your toes with a checkin-needed, since the branch code freeze is in eight hours.
Whiteboard: [checkin-needed: 1.8 branch]
Keywords: checkin-needed → fixed220.127.116.11
Whiteboard: [checkin-needed: 1.8 branch]
Thx Phil! Patrick: this will be in thunderbird 18.104.22.168.
Great news! :)
I can't reproduce this bug cleanly. Can someone verify the fix in the release candidate for TB 22.214.171.124 at ftp://ftp.mozilla.org/pub/thunderbird/nightly/126.96.36.199-candidates/build1/ ?
(In reply to comment #18) > I can't reproduce this bug cleanly. Can someone verify the fix in the release > candidate for TB 188.8.131.52 at > ftp://ftp.mozilla.org/pub/thunderbird/nightly/184.108.40.206-candidates/build1/ ? It also doesn't happen in 100% of the times I click on a search folder for me. I think when Thunderbird is freshly started, it's more likely to happen. Just now I did some testing: TB 220.127.116.11 crashed (verified, multiple times). TB 18.104.22.168rc (downloaded a few minutes ago, used the same profile): I tried ~30 times, restarted it, restarted the whole system, tried again - no crash. So: seems to work! Thanks a lot for fixing this! :)
Marking this as verified then. I sounds like the fix worked. :-)
Keywords: fixed22.214.171.124 → verified126.96.36.199
You need to log in before you can comment on or make changes to this bug.