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.
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
http://climate/reports/searchstacksignature.cfm?stacksig=nsMsgFolderDataSource%3A%3ANotifyAncestors Sure looks like a new topcrash...
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
thanks for fixing it. i really tested well before checking that in. perhaps rv should reflect what is the state of the output!!
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).
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
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!
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.
logged http://bugzilla.mozilla.org/show_bug.cgi?id=122242 on navin.
This has been a topcrasher with recent MozillaTrunk builds. Adding topcrash keyword and [@ nsMsgFolderDataSource::NotifyAncestors] to summary for future reference.
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
*** Bug 121851 has been marked as a duplicate of this bug. ***
Crash Signature: [@ nsMsgFolderDataSource::NotifyAncestors]
You need to log in before you can comment on or make changes to this bug.