Closed Bug 768480 Opened 9 years ago Closed 6 years ago

Mac OSX TB 13 crashes in nsMsgDBFolder::CreateFileForDB when going online. Caused by folder subscribed on server that no longer exists?


(Thunderbird :: General, defect)

13 Branch
Not set


(thunderbird38+ fixed, thunderbird39 fixed, thunderbird40 fixed, thunderbird_esr31+ affected)

Thunderbird 40.0
Tracking Status
thunderbird38 + fixed
thunderbird39 --- fixed
thunderbird40 --- fixed
thunderbird_esr31 + affected


(Reporter: sgay, Assigned: rkent)




(Keywords: crash, testcase, Whiteboard: [startupcrash][rare])

Crash Data


(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

Wipe everything related to TB on the Mac (caches, libraries, profiles, etc).
Fresh-install TB 13.0.1 with no extension, nothing.
Start TB offline and configure an IMAP email account.
Go online.

Actual results:

TB crashes as soon as it goes online.

If TB starts in online mode, it displays the interface then crashes.
If TB starts offline, if works fine until I go online, then crashes.
Same in safe-mode.

Works if offline / not checking mails.
Unchecking "Enable Global Search and Indexer" in prefs does not make a difference.

Expected results:

Should not crash!
By the way, TB 13.0.1 on a Windows 7 works fine reading the same IMAP account.

I was told to "please also mention that crash signature NS_MsgHashIfNecessary is Mac-only" and report the crash ID bp-6a2e9a27-3fc7-4b30-868b-a364f2120626.
Severity: normal → major
OS: Windows 7 → Mac OS X

according to crash stats, crashes are OS X 10.6 and 10.7.

And I find no windows equivalent crashes with NS_MsgHashIfNecessary, nsMsgDBFolder::CreateFileForDB or nsImapMailFolder::CreateClientSubfolderInfo in any crash signature

0	XUL	NS_MsgHashIfNecessary	
1	XUL	nsMsgDBFolder::CreateFileForDB	mailnews/base/util/nsMsgDBFolder.cpp:916
2	XUL	nsImapMailFolder::CreateClientSubfolderInfo	mailnews/imap/src/nsImapMailFolder.cpp:977
3	XUL	nsImapMailFolder::CreateClientSubfolderInfo	mailnews/imap/src/nsImapMailFolder.cpp:961
4	XUL	nsImapIncomingServer::PossibleImapMailbox	mailnews/imap/src/nsImapIncomingServer.cpp:1206
5	XUL	SyncRunnable4<nsIImapServerSink,const nsACString_internal&,char,int,bool*>::Run	mailnews/imap/src/nsSyncRunnableHelpers.cpp:244
6	XUL	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:657
7	XUL	NS_ProcessPendingEvents_P	objdir-tb/x86_64/mozilla/xpcom/build/nsThreadUtils.cpp:195
8	XUL	nsBaseAppShell::NativeEventCallback	widget/xpwidgets/nsBaseAppShell.cpp:130
9	XUL	nsAppShell::ProcessGeckoEvents	widget/cocoa/
10	CoreFoundation	__CFRunLoopDoSources0	
11	CoreFoundation	__CFRunLoopRun	
12	CoreFoundation	CFRunLoopRunSpecific
Severity: major → critical
Crash Signature: [@ NS_MsgHashIfNecessary ]
Ever confirmed: true
Keywords: crash
IMAP:5 protocol log would be helpful -

presumably, the end of the log would show us what folder we were crashing on.
Attached file imap.log
As requested, attached is the imap.log corresponding to a crash.
Looking at the log I thought, is that folder faulty? But, one has to remember that TB13 is quite happy with the very same folder on a Windows 7 PC.
what if you unsubscribe from that folder (temporarily) on windows, and see if you can get your mac build to start.
Went to my ISP webmail and... I was not subscribed to that folder? Yet I see it in TB on Windows, and TB on OSX tries to open it? So I subscribed and now the imap.log ends with:
428883968[118d1fb80]: ReadNextLine [stream=1f3d5510 nb=33 needmore=0]
428883968[118d1fb80]: * LSUB () "/" "Urssaf, Assedic"
428883968[118d1fb80]: ReadNextLine [stream=1f3d5510 nb=36 needmore=0]
428883968[118d1fb80]: * LSUB () "/" "Urssaf, Assedic///"

So the "Urssaf, Assedic" folder is the one I can subscribe/unsubscribe to, and the other one (ending with ///) a rogue folder coming from my ISP? I cannot unsubscribe from it, so it seems.

I should *not* crash TB (and it does not on Windows).
But I'll contact my ISP and ask them what's wrong with that folder.
OK, there is this rogue "Urssaf, Assedic///" that the server thinks I'm subscribed to, even though it does not exist anymore. And I can not unsubscribe because it does not exist. Trying to sort out things with the ISP.

Nevertheless, it should not crash TB.
The rogue folder has been deleted by the ISP and TB does not crash anymore. So that seem to have been the cause. Now, TB should not have crashed anyway.
bienvenu, wada, I find only Mac and linux crashes. previous patch with this signature is bug 562104

other examples: bp-e930ded8-3597-4d8f-80e8-fca5e2120630 bp-c0e6bf52-c69c-4e0e-a217-a5da72120613
Summary: Mac OSX TB 13 crashes when going online → Mac OSX TB 13 crashes in nsMsgDBFolder::CreateFileForDB when going online
This crash signature is gone in version 24.x.

New in version 24 is [@ NS_MsgHashIfNecessary(nsAutoString&) ]  however, none of the stacks I looked at contain nsMsgDBFolder::CreateFileForDB 

But perhaps the steps are still valid. SOmeone able to test on a Mac?
Keywords: testcase
Whiteboard: [closeme 2014-01-01]
Resolved per whiteboard
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2014-01-01]
It is back.

user in
 0 	XUL	NS_MsgHashIfNecessary(nsAutoString&)	mailnews/base/util/nsMsgUtils.cpp
1 	XUL	nsMsgDBFolder::CreateFileForDB(nsAString_internal const&, nsIFile*, nsIFile**)	mailnews/base/util/nsMsgDBFolder.cpp
2 	XUL	nsImapMailFolder::CreateClientSubfolderInfo(nsACString_internal const&, char, int, bool)	mailnews/imap/src/nsImapMailFolder.cpp
3 	XUL	nsImapMailFolder::CreateClientSubfolderInfo(nsACString_internal const&, char, int, bool)	mailnews/imap/src/nsImapMailFolder.cpp
4 	XUL	nsImapIncomingServer::PossibleImapMailbox(nsACString_internal const&, char, int, bool*)	mailnews/imap/src/nsImapIncomingServer.cpp
5 	XUL	(anonymous namespace)::SyncRunnable4<nsIImapServerSink, nsACString_internal const&, char, int, bool*>::Run()	mailnews/imap/src/nsSyncRunnableHelpers.cpp
 hg@0 	932  // Create an empty database for this mail folder, set its name from the user
hg@0 	933  nsCOMPtr<nsIMsgDatabase> mailDBFactory;
hg@0 	934  nsCOMPtr<nsIMsgFolder> child;
hg@0 	935
hg@0 	936  nsCOMPtr<nsIMsgDBService> msgDBService = do_GetService(NS_MSGDB_SERVICE_CONTRACTID, &rv);
hg@0 	937  NS_ENSURE_SUCCESS(rv, rv);
hg@0 	938  nsCOMPtr<nsIMsgDatabase> unusedDB;
geoff@12584 939 nsCOMPtr <nsIFile> dbFile;
hg@0 	940
hg@0 	941 // warning, path will be changed
bienvenu@1936 942 rv = CreateFileForDB(folderNameStr, path, getter_AddRefs(dbFile));
hg@0 	907 // path coming in is the root path without the leaf name,
hg@0 	908 // on the way out, it's the whole path.
geoff@12584 909 nsresult nsMsgDBFolder::CreateFileForDB(const nsAString& userLeafName, nsIFile *path, nsIFile **dbFile)
hg@0 	910 {
hg@0 	911    NS_ENSURE_ARG_POINTER(dbFile);
hg@0 	912
bienvenu@1936 	913 nsAutoString proposedDBName(userLeafName);
hg@0 	914  NS_MsgHashIfNecessary(proposedDBName);
Crash Signature: [@ NS_MsgHashIfNecessary ] → [@ NS_MsgHashIfNecessary ] [@ NS_MsgHashIfNecessary(nsAutoString&)]
Resolution: INCOMPLETE → ---
Summary: Mac OSX TB 13 crashes in nsMsgDBFolder::CreateFileForDB when going online → Mac OSX TB 13 crashes in nsMsgDBFolder::CreateFileForDB when going online. Caused by folder subscribed on server that no longer exists?
This code causes name[-1] to be read if the length of the passed string is zero. We should protect against this:
Assignee: nobody → rkent
I'm not sure if this is causing the crash or not, but this method should have protection against zero length string.
Attachment #8589203 - Flags: review?(neil)
Comment on attachment 8589203 [details] [diff] [review]
Check length of string before decrementing

* Protect both overloads for consistency. r=me with that fixed.
* Prefer to early return in the case of an empty string.
* Prefer use of IsEmpty() to check for empty string.
Attachment #8589203 - Flags: review?(neil) → review+
Checked in

We'll consider taking this simple patch in TB 38, also possibly TB 31.
Closed: 7 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 40.0
Attachment #8589203 - Flags: approval-comm-beta?
Attachment #8589203 - Flags: approval-comm-aurora?
Comment on attachment 8589203 [details] [diff] [review]
Check length of string before decrementing
Attachment #8589203 - Flags: approval-comm-beta?
Attachment #8589203 - Flags: approval-comm-beta+
Attachment #8589203 - Flags: approval-comm-aurora?
Attachment #8589203 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.