Last Comment Bug 520006 - Crash while using Search bar in folder Grouped By Sort [@]
: Crash while using Search bar in folder Grouped By Sort [@
: crash, fixed-seamonkey2.0
Product: MailNews Core
Classification: Components
Component: Backend (show other bugs)
: Trunk
: x86 All
-- critical (vote)
: ---
Assigned To: David :Bienvenu
Depends on:
  Show dependency treegraph
Reported: 2009-10-01 10:15 PDT by Michal Kec (MiK)
Modified: 2011-06-09 14:58 PDT (History)
5 users (show)
iann_bugzilla: blocking‑seamonkey2.0+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

proposed fix (2.47 KB, patch)
2009-10-13 08:00 PDT, David :Bienvenu
neil: review+
neil: superreview+
kairo: approval‑seamonkey2.0+
Details | Diff | Splinter Review

Description User image Michal Kec (MiK) 2009-10-01 10:15:55 PDT
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: Gecko/20090717 SeaMonkey/2.0b1
Mozilla/5.0 (X11; U; Linux i686; cs; rv: Gecko/20091001 SeaMonkey/2.0pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20091001 SeaMonkey/2.0pre
Windows beta 1 crashed too.

Comment 1 User image :Hb 2009-10-04 14:16:26 PDT
(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.
Comment 2 User image lenochod 2009-10-04 21:58:53 PDT
Please try in Safe mode ( ), or with a new profile ( ).

Is this an official 32bit build from our downloads server ( or a contributed 64bit build? x86_64 builds are not officially supported ( ).
Comment 3 User image :Hb 2009-10-05 02:21:10 PDT
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 Crash can't be reproduced. Tested on folder with 26 messages.

Spinoff is bug 520527.
Comment 4 User image 2009-10-05 02:22:33 PDT
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
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.
Comment 5 User image 2009-10-05 03:31:12 PDT
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...
Comment 6 User image Ian Neal 2009-10-05 15:42:09 PDT
Do we have a regression window?
Comment 7 User image Robert Kaiser 2009-10-06 05:44:16 PDT
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?
Comment 8 User image Serge Gautherie (:sgautherie) 2009-10-06 08:39:51 PDT
[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: Gecko/20091006 SeaMonkey/2.0pre] (nightly) (W2Ksp4)

Tried a few times, but no crash and results seemed to be fine at first glance :-|
Comment 9 User image Wayne Mery (:wsmwk, NI for questions) 2009-10-07 11:17:54 PDT
the stacks of the crashes in comment 0 don't appear to have anything to do with mail :(   what's up with that?
Comment 10 User image David :Bienvenu 2009-10-07 17:15:01 PDT
I'll try a SM build just in case our dbviewwrapper is making this harder to recreate in TB.
Comment 11 User image David :Bienvenu 2009-10-08 16:04:24 PDT
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.
Comment 12 User image Robert Kaiser 2009-10-13 06:33:42 PDT
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?
Comment 13 User image David :Bienvenu 2009-10-13 07:57:46 PDT
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...
Comment 14 User image David :Bienvenu 2009-10-13 08:00:59 PDT
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 15 User image 2009-10-13 08:18:27 PDT
Comment on attachment 406017 [details] [diff] [review]
proposed fix

Things seem to work correctly with my sample of 801 messages.
Comment 16 User image Robert Kaiser 2009-10-13 08:29:05 PDT
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.
Comment 17 User image David :Bienvenu 2009-10-13 09:51:57 PDT
fix checked in.

Note You need to log in before you can comment on or make changes to this bug.