Closed
Bug 386692
Opened 17 years ago
Closed 17 years ago
NS_ENSURE-TRUE(aFile) warning dumped to console during Thunderbird startup
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mscott, Assigned: mscott)
Details
Attachments
(1 file)
606 bytes,
patch
|
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
On starting up Thunderbird, I get the following warning dumped to the console several times:
WARNING: NS_ENSURE_TRUE(aFile) failed: file c:/build/trees/tb-trunk/mozilla/xpco
m/io/nsLocalFileWin.cpp, line 870
The stack trace looks like:
> nsMsgDBFolder::GetFilePath() Line 4021 C++
nsMsgDBFolder::GetFolderCacheKey() Line 1068 C++
nsMsgDBFolder::ReadDBFolderInfo() Line 524 C++
nsMsgDBFolder::GetFlags() Line 1037 C++
nsMsgDBFolder::AddSubfolder() Line 3044 C++
nsMsgLocalMailFolder::AddSubfolder() Line 270 C++
nsMsgLocalMailFolder::CreateSubFolders() Line 255 C++
nsMsgLocalMailFolder::GetSubFolders() Line 407 C++
nsMsgFolderDataSource::createFolderOpenNode() Line 1409 C++
nsMsgFolderDataSource::createFolderNode() Line 993 C++
nsMsgFolderDataSource::GetTarget() Line 437 C++
GetTargetHasAssertion() Line 100 C++
The problem is that the folder in question was created via RDF and not by us, so it doesn't have a parent folder, it doesn't have an incoming server, etc. so ParseURI fails to give us a file back and we end up asserting.
This happens because...
The folder data source is creating a node for a root folder (an RSS server in this case). This ends up calling nsMsgDBFolders::GetSubFolders on the root folder. We discover the specific sub folder on disk and try to add it. nsMsgDBFolder::AddSubFolder gets the RDF service calls GetResource on a URI that maps to the sub folder. This triggers the creation of a new nsMsgDBFolder object via RDF. It doesn't look like we've created the folder for 'real' yet leaving us with an object that doesn't have an incoming server or a root folder hooked up to it yet.
Here's the stack trace showing the creation of this incomplete folder as a child from an RSS server.
nsMsgDBFolder::nsMsgDBFolder() Line 186 C++
nsMsgLocalMailFolder::nsMsgLocalMailFolder() Line 162 C++
nsMsgLocalMailFolderConstructor() Line 461 C++
nsGenericFactory::CreateInstance() Line 80 C++
RDFServiceImpl::GetResource() Line 1022 C++
nsMsgDBFolder::AddSubfolder() Line 3030 C++
nsMsgLocalMailFolder::AddSubfolder() Line 270 C++
nsMsgLocalMailFolder::CreateSubFolders() Line 255 C++
nsMsgLocalMailFolder::GetSubFolders() Line 407 C++
nsMsgFolderDataSource::createFolderOpenNode() Line 1409 C++
nsMsgFolderDataSource::createFolderNode() Line 993 C++
nsMsgFolderDataSource::GetTarget() Line 437 C++
GetTargetHasAssertion() Line 100 C++
nsMsgFolderDataSource::DoFolderHasAssertion() Line 2202 C++
nsMsgFolderDataSource::HasAssertion() Line 552 C++
nsXULTreeBuilder::IsContainerOpen() Line 1793 C++
Assignee | ||
Comment 1•17 years ago
|
||
Oh and right after I get the warning about aFile, I get another assertion from the folder cache: WARNING: NS_ENSURE_TRUE(!pathKey.IsEmpty()) failed: file c:/build/trees/tb-trunk /mozilla/mailnews/base/src/nsMsgFolderCache.cpp, line 291 I'm pretty sure if we fix the cause of the file assertion, this will get fixed too.
Assignee | ||
Comment 2•17 years ago
|
||
This fixes the following two warnings I see in the console: WARNING: NS_ENSURE_TRUE(aFile) failed: file c:/build/trees/tb-trunk/mozilla/xpco m/io/nsLocalFileWin.cpp, line 870 and WARNING: NS_ENSURE_TRUE(!pathKey.IsEmpty()) failed: file c:/build/trees/tb-trunk /mozilla/mailnews/base/src/nsMsgFolderCache.cpp, line 291 I think this is some minor fall out from the nsFileSpec removal. nsMsgDBFolder::GetFilePath used to pass in PR_TRUE to parseURI, the bool argument was dropped when we migrated to nsILocalFile. See the old implementation for nsMsgDBFolder::GetPath vs. the new code in GetFilePath: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=/mozilla/mailnews/base/util&command=DIFF_FRAMESET&file=nsMsgDBFolder.cpp&rev2=1.300&rev1=1.299 As a result ParseURI was no longer falling back to asking the account manager for the incoming server associated with the folder URL. This was leading to the errors down stream with the folder cache and nsLocalFileWin (our path for the database was an empty string)
Comment 3•17 years ago
|
||
Comment on attachment 270767 [details] [diff] [review] the fix thx for cleaning this up, Scott. I wonder if before we were counting on going through the filespec routine first...
Attachment #270767 -
Flags: superreview?(bienvenu) → superreview+
Comment 4•17 years ago
|
||
heh, I ran into this bug 30 minutes later working on the command line parsing stuff.
Assignee | ||
Updated•17 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 5•15 years ago
|
||
David, stephend set in-litmus? in bug 386425. Is a test warranted for this bug, or bug 386425?
You need to log in
before you can comment on or make changes to this bug.
Description
•