121876 - Crash in Trunk [@ nsMsgFolderDataSource::NotifyAncestors]

Status: VERIFIED FIXED

(MailNews Core :: Database, defect)

Description

[Jean-Francois Ducarroz]

I was starting last night debug build while a Netcape release build was aleredy
running using the same profile (btw: I do that all the time without problem).
The debug build crash in nsMsgFolderDataSource::NotifyAncestors because
aFolder->GetParentMsgFolder return a null parent folder but no error! We then
crash  trying to access member function of the parent folder.

Comment 1

[Blake Ross]

Today I had mailnews (and a message) open in the Classic theme, I switched to
Modern, I clicked another message, and I crashed.  That happens to me a lot, but
when I restarted and tried to open mailnews I crashed with this stack --
reproducibly.  So, since I can't open mailnews anymore (!), anyone mind if I
bump this up to blocker? ;)

Comment 2

[Blake Ross]

http://climate/reports/searchstacksignature.cfm?stacksig=nsMsgFolderDataSource%3A%3ANotifyAncestors

Sure looks like a new topcrash...

Comment 3

[David :Bienvenu]

I've checked in a check for a null parent folder. I'm a little confused why this
just started happening since the last time I changed this code was Dec. 4th.  -
perhaps it was Navin's change on Jan 24th that caused this, and not my change?

Comment 4

[Navin Gupta]

thanks for fixing it. i really tested well before checking that in. perhaps
rv should reflect what is the state of the output!!

Comment 5

[David :Bienvenu]

Despite JF's assertion that he does this all the time w/o problems, I'm
absolutely positive it causes lots of problems to run two instances against the
same profile, and he should mention that prominently in every mail bug he files
from now on! I'm not sure why GetParentMsgFolder would be null - it might be
that a corrupt panacea.dat causes this crash, or it could be something like
starting up with a local folder hierarchy collapsed causes this crash. Yes,
GetParentMsgFolder should return an error if the callers aren't going to check
for null parents...but you need to be careful about propagating the error, in
case that causes other problems (NS_ENSURE_SUCCESS(rv, rv) will propagate the
error).

Comment 6

[[not reading bugmail]]

FWIW, regarding comments from bienvenu: I used to frequently run Netscape &
Mozilla at the same time, mostly with seperate profiles, but once in a while
with the same profile, and it can be a real problem, especially with Quick
Launch, Mail, & Default System file handling can be affected by this.  I think
it something that should be addressed, I found that using mozilla on netscape's
profile with mail, actually horks the mail stuff weather it is the folders, or
the XUL code or other stuff.  I find I can't access my Webmail after I do this
with running netscape afterward.  It doesn't like the profile being access the
same time or by Mozilla.  To get back to normal I have to delete my Imap mail
account and create a new one before Netscape will retrieve my mail again from
Webmail.

Regarding the desktop integration problem: bug 69372

Comment 7

[Jean-Francois Ducarroz]

Bienvenu, If I report a bug while running 2 instances on the same profile, I add
this precious piece of info in the bug report like I did for this one.

Anyway, sofar the only problem I saw when runnuing 2 builds using the same
profile is that often, the Mozilla or Netscape need to reload my whole inbox!

Comment 8

[David :Bienvenu]

JF, the problems can just as easily occur during some future run of just one
client instance, not neccessarily while you're running two instances at the same
time. Which is what I should have said earlier, sorry for the confusion.

Comment 9

[(not reading, please use [e-mail] instead)]

thanks for fixing this.   here's what bienvenu checked in:

nsCOMPtr <nsIMsgFolder> parentMsgFolder;                                      
rv = aFolder->GetParentMsgFolder(getter_AddRefs(parentMsgFolder));            
NS_ENSURE_SUCCESS(rv,rv);                                                     
+if (!parentMsgFolder)                                                         
+  return NS_OK;          
 
this was recently added to the nsIMsgFolder interface:

  /* handy accessor when we want a msg folder */
  readonly attribute nsIMsgFolder parentMsgFolder;

we should:

1)  extend that comment to specify that if the folder doesn't have a parent, it 
can return null.  (does that happens when we call GetParentMsgFolder on a root 
folder, right?)

2)  check the other callers (C++ and js) to make sure they handle this case 
correctly.

I'll spin up a new bug on this.

Comment 10

[(not reading, please use [e-mail] instead)]

logged http://bugzilla.mozilla.org/show_bug.cgi?id=122242 on navin.

Comment 11

[Jay Patel [:jay]]

This has been a topcrasher with recent MozillaTrunk builds.  Adding topcrash
keyword and  [@  nsMsgFolderDataSource::NotifyAncestors] to summary for future
reference.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

This last occured in the 27th builds, and I also tried Blake's testcase.  I
crashed, but in unrelated code (nsRuleNode::WalkRuleTree 91057978 and
ReleaseSheet
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 474] ).

Verified FIXED.

Comment 13

[timeless]

*** Bug 121851 has been marked as a duplicate of this bug. ***