Crash in Trunk [@ nsMsgFolderDataSource::NotifyAncestors]

VERIFIED FIXED

Status

MailNews Core
Database
--
blocker
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Jean-Francois Ducarroz, Assigned: Bienvenu)

Tracking

({crash, topcrash})

Trunk
x86
Windows 2000
crash, topcrash

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

17 years ago
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

17 years ago
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? ;)
Severity: normal → blocker
Keywords: crash, nsbeta1
(Assignee)

Comment 3

17 years ago
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?
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 4

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

Comment 5

17 years ago
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

17 years ago
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
(Reporter)

Comment 7

17 years ago
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!
(Assignee)

Comment 8

17 years ago
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.
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 11

17 years ago
This has been a topcrasher with recent MozillaTrunk builds.  Adding topcrash
keyword and  [@  nsMsgFolderDataSource::NotifyAncestors] to summary for future
reference.
Keywords: topcrash
Summary: Crash in nsMsgFolderDataSource::NotifyAncestors → Crash in Trunk [@ nsMsgFolderDataSource::NotifyAncestors]
QA Contact: esther → stephend
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.
Status: RESOLVED → VERIFIED

Comment 13

15 years ago
*** Bug 121851 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
Crash Signature: [@ nsMsgFolderDataSource::NotifyAncestors]
You need to log in before you can comment on or make changes to this bug.