Steps to reproduce: 1. Set an IMAP account 2. Set View, Sort by, Grouped By Sort on any folder 3. With focus on this folder (folderpane) write some string into the Search bar (i.e. inputbox "Search Subject or Address") - e.g. "mozilla" 4. Don't blur that inputbox, don't clear the string 5. Select the written string (e.g. by Shift+Home) and write new one - e.g. "seamonkey" 6. Note zero results (even if some messages should match the query) 7. Repeat step 5 8. SeaMonkey suddenly crashes Thus repeated searching within one folder is almost impossible. Reproducible: always Tested on: Mozilla/5.0 (X11; U; Linux i686; cs; rv:22.214.171.124pre) Gecko/20090717 SeaMonkey/2.0b1 Mozilla/5.0 (X11; U; Linux i686; cs; rv:126.96.36.199pre) Gecko/20091001 SeaMonkey/2.0pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52pre) Gecko/20091001 SeaMonkey/2.0pre Windows beta 1 crashed too. Crashreports: http://crash-stats.mozilla.com/report/index/baa0a37f-d565-4862-923a-ef9852090803 http://crash-stats.mozilla.com/report/index/f78b4d6d-d7f0-4b99-b665-f01c32090803 http://crash-stats.mozilla.com/report/index/724091b1-c0b8-4df5-8299-db4102090812 http://crash-stats.mozilla.com/report/index/b38b9ff9-9d69-498f-a4d7-9c2562090924
(In reply to comment #0) > 2. Set View, Sort by, Grouped By Sort on any folder Which main criteria for "Sort by" setting? Ascending or Descending? Is it necessary to set this on any folder? > 6. Note zero results (even if some messages should match the query) With Sort by "Subject, Ascending, Grouped by Sort" on Inbox I got bad search results too. Content in subject was "Rundschreiben". Typing "rund" gave good results. Narrowing the search term by typing "sch" a few seconds later after the results were delivered to "rundsch" started the search again. This second search failed completely and didn't gave back any results. Quicly typing "rundsch" without a pause gave good search results. > 8. SeaMonkey suddenly crashes SM 2.0 pre 20090928 under Win XP never crashed here.
Please try in Safe mode ( http://kb.mozillazine.org/Talk:Safe_Mode#Safe_Mode_in_SeaMonkey_2 ), or with a new profile ( http://kb.mozillazine.org/Profile_Manager#Creating_a_new_profile ). Is this an official 32bit build from our downloads server (ftp://ftp.mozilla.org/pub/seamonkey/releases/) or a contributed 64bit build? x86_64 builds are not officially supported ( http://www.seamonkey-project.org/releases/2.0b2#contrib ).
Error is bad search results on second search run. Sometimes results are zero and sometimes they are wrong. It occurs in new profile on latest nightly too. It occurs on POP3 accounts too. It is independent of main Sort by criteria. After fiddling around an hour and having Sort by: From and Grouped By Sort set I got http://crash-stats.mozilla.com/report/index/bp-0f656d3e-3402-468d-8a26-ea1812091005 Crash can't be reproduced. Tested on folder with 26 messages. Spinoff is bug 520527.
So, this crashed out straight away in my debug build: >###!!! ASSERTION: invalid array index: 'i < Length()', file c:\hg\mozilla\dist\include\nsTArray.h, line 317 Called from nsMsgGroupView::AddHdrToThread, line 399: > // update the root node's header (in the view) to be the same as the root > // node in the thread. > SetMsgHdrAt(msgHdr, viewIndexOfThread, msgKey, > (msgFlags & ~(nsMsgMessageFlags::Elided)) | > // maintain elided flag and dummy flag > (m_flags[viewIndexOfThread] & (nsMsgMessageFlags::Elided > | MSG_VIEW_FLAG_DUMMY)) > // ensure thread and has-children flags are set > | MSG_VIEW_FLAG_ISTHREAD | MSG_VIEW_FLAG_HASCHILDREN, 0); Unfortunately viewIndexOfThread is 0xFFFFFFFF. I tried setting viewIndexOfThread to 0 and continuing, but I didn't get very far: in fact the same assertion was triggered, but this time it was trying to update row 0 although in fact the arrays were empty.
Bah, and when I tried to switch back into threaded mode it didn't work at all well, I had to click through several assertions and switch folders...
Do we have a regression window?
This is marked as a 2.0 blocker, so should be fixed in time for code freeze, which is in mere 18 hours. Can we have _some_ progress on this or decide to not block on it after all? What's the risk of shipping RC1 without it? How do things look for RC2/final?
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20090928 SeaMonkey/2.1a1pre] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:184.108.40.206pre) Gecko/20091006 SeaMonkey/2.0pre] (nightly) (W2Ksp4) Tried a few times, but no crash and results seemed to be fine at first glance :-|
the stacks of the crashes in comment 0 don't appear to have anything to do with mail :( what's up with that?
I'll try a SM build just in case our dbviewwrapper is making this harder to recreate in TB.
yeah, this is pretty easy to reproduce in SM - I can't reproduce it in TB, though I think there are some stacks like this in crashpad for TB. Taking.
This is marked blocking 2.0 but we should be cutting the final RC any day now (actually, any day after today makes us probably slip the ideal release date) - so any ETA to get this resolved?
We can paper over the crash but these multiple quick searches in grouped views are broken in SM, in the sense that you often don't get any results when you should. The backend shouldn't crash, however. I dug a little more into this and I have a fix for Neil to try out...
Created attachment 406017 [details] [diff] [review] proposed fix I haven't tried this out in TB yet (it shouldn't break anything, but I need to make sure), nor have I run the tests against it yet. The good news is that with this patch, quick searches in this mode seem to work a lot better with SM. What seems to be happening is that the groups table isn't getting cleared out between quick searches, though the view arrays are getting cleared out. This leads to some confusion down the road. This patch fixes it as it goes, though we should figure out why the groups table isn't getting cleared. As I said before, I think the dbviewwrapper that TB uses is probably the reason TB doesn't seem to have this problem.
Comment on attachment 406017 [details] [diff] [review] proposed fix Things seem to work correctly with my sample of 801 messages.
Comment on attachment 406017 [details] [diff] [review] proposed fix From my side, I'm perfectly happy with this and would hope to have it landed ASAP so we are clear for the (hopefully) final 2.0 RC. I guess we probably will switch to the same mechanism as TB for the next release series, which might just kill the root problem as well, then.
fix checked in.