383584 - crashed while getting message (after rename a virtual folder) [@ VirtualFolderChangeListener::OnHdrAdded(nsIMsgDBHdr*, unsigned int, int, nsIDBChangeListener*)]

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[Yuxuan Wang]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: version 2.0.0.0 (20070326)

Thunderbird crashed while retrieving new message match a search criteria of a renamed virtual folder., after restart Thundebird, the newest message will got 2 copies in the inbox.
crash report will be posted later.

Reproducible: Always

Steps to Reproduce:
1.Create a virtual folder
2.Rename this virtual folder
3.Send a mail to yourself that match the search criteria of the virtual folder
4.Get message for that account
Actual Results:  
Thunderbird crashed
After restart, there will be 2 copies of that message.

Expected Results:  
Thunderbird works ok and the message won't be duplicated.

Comment 1

[Yuxuan Wang]

Attachment: crash report 1

Comment 2

[Yuxuan Wang]

Attachment: crash report 2

Comment 3

[Wayne Mery (:wsmwk)]

still see this problem with version 2.0.0.9?
if no please close bug
if yes, post talkback id.  

Comment 4

[Wayne Mery (:wsmwk)]

on trunk with same stack bp-6ae29d59-e4a4-11dc-bb85-001a4bd43ef6 (SM windows - the only one on crash-stats).

perhaps related to bug 340652, which is reported against v1.5. (slightly different stack - but top 3 frames are same)

Comment 5

[Yuxuan Wang]

I can't get Talkback Agent enabled on Mac (I found the app and run it and enabled it, but it just didn't collect information after crash), but I DO can reproduce it on 2.0.14, following the steps.

Comment 6

[Wayne Mery (:wsmwk)]

bienvenu, anything land last week that you think may have fixed this?  Last trunk crash is 20090603 build. Only think you landed on 6/3 is bug 414723

(is actually a topcrash for 3.0b3pre)

http://crash-stats.mozilla.com/report/list?product=Thunderbird&version=Thunderbird%3A3.0b3pre&query_search=signature&query_type=contains&query=&date=&range_value=31&range_unit=days&do_query=1&signature=VirtualFolderChangeListener%3A%3AOnHdrAdded%28nsIMsgDBHdr*%2C%20unsigned%20int%2C%20int%2C%20nsIDBChangeListener*%29

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> bienvenu, anything land last week that you think may have fixed this?  Last
> trunk crash is 20090603 build. Only think you landed on 6/3 is bug 414723

that turned out to be incorrect - still a topcrash on trunk(#15), but not a topcrash for 3.0b2 (#89). not sure why the disparity. So for that reason, not requesting blocking.
example bp-cd2b1e22-4d92-457e-b111-4bd272090708

Comment 8

[Magnus Melin [:mkmelin]]

The crash is here: http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp#2561 on 
m_searchSession->AddScopeTerm(nsMsgSearchScope::offlineMail, m_folderWatching);

On http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp#2417 we have

if (NS_SUCCEEDED(rv) && msgDB)

Comment 9

[Magnus Melin [:mkmelin]]

The crash is here: http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp#2561 on 
m_searchSession->AddScopeTerm(nsMsgSearchScope::offlineMail, m_folderWatching);

On http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgAccountManager.cpp#2417 we have

if (NS_SUCCEEDED(rv) && msgDB)
  ...
  // set up m_searchSession
  ...
return rv;...

So m_searchSession could be null if that happens. Maybe that should return some error code if !msgDB?

Comment 10

[David :Bienvenu]

taking - I can reproduce this...

Comment 11

[David :Bienvenu]

https://bugzilla.mozilla.org/show_bug.cgi?id=490326#c18 - the crash described there is this crash. Patch upcoming.

Comment 12

[David :Bienvenu]

Attachment: proposed fix

There are a couple fixes in this patch.

The first is that if we fail to initialize the virtualFolderChangeListener, we shouldn't add it as a listener. This can happen if the vf db is missing. For good measure, I also null check the m_searchSession.

The second fix is when loading saved searches, and the db is missing, we were corrupting the previous saved search with properties from the saved search with the missing db. Nulling out the db folder info when we parse a uri term line fixes that.

Comment 13

[Mark Banner (:standard8)]

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

I couldn't reproduce the crash, but this looks good anyway.

Comment 14

[David :Bienvenu]

fix checked in.

Comment 15

[Wayne Mery (:wsmwk)]

as of today this is #12 crasher for 3.0b3 and the last crash is build
20090715142648 (3.0b3). however, crashes in nightlies were so rare that I don't think we'll know this is totally gone until we can check 3.0b4 

TB20022 - this is #100 in topcrash list, so doubt it will rate pushing to v2.