520006 - Crash while using Search bar in folder Grouped By Sort [@ libfontconfig.so.1.3.0@0x151f0]

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Michal Kec (MiK)]

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:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1
Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9.1.4pre) Gecko/20091001 SeaMonkey/2.0pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) 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

Comment 1

[:Hb]

(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

[lenochod]

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 ).

Comment 3

[:Hb]

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.

Comment 4

[[e-mail]]

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.

Comment 5

[[e-mail]]

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

[Ian Neal]

Do we have a regression window?

Comment 7

[Robert Kaiser]

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

[Serge Gautherie (:sgautherie)]

[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:1.9.1.4pre) 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

[Wayne Mery (:wsmwk)]

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

[David :Bienvenu]

I'll try a SM build just in case our dbviewwrapper is making this harder to recreate in TB.

Comment 11

[David :Bienvenu]

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

[Robert Kaiser]

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

[David :Bienvenu]

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

[David :Bienvenu]

Attachment: 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

[[e-mail]]

Comment on attachment 406017 [details] [diff] [review]
proposed fix

Things seem to work correctly with my sample of 801 messages.

Comment 16

[Robert Kaiser]

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

[David :Bienvenu]

fix checked in.