Closed Bug 903451 Opened 11 years ago Closed 11 years ago

Very slow program startup if getting new mail. proxy related

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 923458

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [regression?]) 

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 (Beta/Release)
Build ID: 20130803200314

Steps to reproduce:

Installed Seamonkey 2.20 on Windows XP in a VMware virtual machine.
Replaced version 2.14.1



Actual results:

Program is starting much, much slower.  First about 3 seconds of 100% CPU, then
it falls back in CPU use but does not progress.  Disk does not rattle (no swapping).
When starting with -mail, after some time the accounts and folders list appears
but the message list area remains grey for about 10 more seconds.
Then program springs alive and works at normal performance.

Tracing reveals no suspicious network activity.   Server (IMAP) is connected OK.



Expected results:

2.14.1 worked fine on same system.
From the command line, start SeaMonkey with -safe-mode switch.
e.g. /path/to/seamonkey.exe -safe-mode
Does your start up times improve?
No, it remains about the same.   I tried seamonkey.exe -mail -safe-mode
The dialog box informing me what safe mode is appears very quickly, and when I click the
continue button it reasonably quickly displays the mail window (I would say with similar
performance as previously for the entire startup), but then that window shows only the
folderlist and it again takes a long time before the messagelist and the function buttons
appear.  The total time may have been a little less than for the normal startup, but not
much.
When it first starts up with -mail does it have the window but none of the icons?
Do you know what version it started happening with?
Yes, that is right.  It shows the mail window with only the folder list,
the message list area is all greyed (the handle between message list and
mail preview is completely at the bottom), and in the icon area there are
only some rudimentary lines but no icons.  It is also greyed.
Then, after at least 10 seconds it suddenly springs into life and the
message preview area apprears (handle goes up to halfway) and so does the
message list.
I don't know when exactly it started, I tracked the versions on my system
at home which runs Linux and this issue does not appear there.
The system where this happens is on an isolated LAN (no internet routing)
which does have a DNS forwarder and a proxy server.  The system has a local
firewall that forbids all outgoing traffic outside the LAN address range.
If there would be an attempt to "phone home" during startup, that would not
respect the proxy settings, it could cause such a stall.  I have not yet
identified that, however.
I'm also seeing this on Windows 2008R2 (thought it was a Citrix issue but obviously not), I will try and find some time to do some regression testing.
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
procmon trace would be useful, but I would start from erasing cache folder and compacting mail
Testing with a different account and removing all .msf files hints in the
direction that the startup time is proportional to the number of .msf files.
An account with only standard folders starts much quicker than my own account,
and after the removal of .msf files mine started quicker as well.  However
after the program is shut down and restarted (now with empty .msf files as
I have not yet visited all those folders) it is just as slow as before.
Is your profile on a Network drive?
Do you have some sort of anti-virus scanning software that checks your email?
Profile is part of roaming Windows profile, so is locally stored on harddisk.
Virusscanner NOD32 is scanning only files and http, not IMAP e-mail.
Systems are installed using scripts, identical system with Seamonkey 2.14.1
has no issue.  Same profile on another system works fine.
Shutdown SeaMonkey. Make sure no SM processes are running.
In the profile that has the slow behaviour.
Look at the directory that corresponds to the profile.
Locate a file called "localstore.rdf"
Move it somewhere else (do not delete)
Start up SeaMonkey again.
Does this make the startup faster? slower? no change?
I tried that.  It is even slower, I think.  Forgot to time it exactly but it
feels like that.  I restored the original file and my window settings come back
as they were, but startup still slow.
Also removed a localstore-safe.rdf that I never saw before, but there is no
difference.  It does not come back.
I have done further testing with the firewall disabled.
With an account that has 3 IMAP mail accounts, when starting seamonkey -mail
and tracing network activity I see the program connect the 3 mail accounts
briefly during the long startup time, and there is no other network activity.

So it definately is not a "phone home" problem.  It appears each IMAP
account is opened, the server accessed, and then the program spends a
lot of time (i.e. a lot more than old versions) processing the folders
and maybe the .msf files.   When that is all done, it displays the message
list of the first account and the start page of the mail.  The CPU is
not heavily loaded during that processing, and neither is the network.
So, what about procmon or xperf trace?
Tested on Windows 2003R2 enterprise Citrix.   Same slow startup for same config.
During one of the tries it crashed while the grey screen was displayed.
Crash ID bp-ce3e2bfb-1420-4b23-be04-baf9f2130829
(In reply to Phoenix from comment #13)
> So, what about procmon or xperf trace?

Please explain!
Thank you.   I have made a trace with ProcessMonitor and examined it.  It contains too
much local personal information to post it, but there are a couple of interesting things:

- during the time it is starting the mail it makes very many consecutive calls to the
  function QueryStandardInformationFile for the file msgFilterRules.dat in the ImapMail
  directory in the profile (in a subdir related to each mail account)
  those calls all return SUCCESS but the program makes no other calls involving the file.
- after a couple hundred of those calls it finally reads the file.
- it proceeeds to read some of the .msf files, apparently the ones for folders that have
  been marked as being watched for new messages
- then there is exactly 3 seconds in which there is no activity logged
- the program then proceeds to the next mail account, again making many calls to the
  msgFilterRules.dat file as described in the first point

Both the many QueryStandardInformationFile calls and the exactly 3 second (to within .02
second!) pause do worry me.
"QueryStandardInformationFile for the file msgFilterRules.dat" - it may just enumerate all filters, but this looks more like MailCore issue. Next check last call before that 3 sec timeout and look at it's stack. Also, may be useful to sort/filter by call duration.
Two more things - https://wiki.mozilla.org/MailNews:Logging and http://kb.mozillazine.org/Modify_Thunderbird_settings#Change_connection_timeout
The last call in the sequence before the pause is not always the same.  In two cases it
is a QueryOpen on the last .msf file that has just been read above that, and after the
last mail account it is a ThreadCreate (the QueryOpen is just above it).
In the 3 second pauses, infrequent calls are made by other processes but they do not
appear to be related.  I see no systemcall for a 3 second pause or anything that would
timeout.  When it continues it is QueryOpen again, this time for Local Folders.
The calls do not take long, there is just a long pause.

The pauses can be seen in the log:
2013-08-30 19:42:12.788000 UTC - 2680[aeebb00]: ImapThreadMainLoop entering [this=d00f000]
2013-08-30 19:42:15.788000 UTC - 2680[aeebb00]: d00f000:mail.uw:NA:ProcessCurrentURL: entering
This happens way before it even tries to log in to the server.

I do not understand why I don't see the server dialogue in the ProcessMonitor trace.
Shouldn't there be network-related system calls shown there?
Ludovic, can you look at last comment and maybe advice something?
Flags: needinfo?(ludovic)
I have downloaded the sources, and opened mailnews/imap/src/nsImapProtocol.cpp where those
two messages are logged on lines 1294 and 1529.  The call to the function at 1529 is from
line 1347.  So the 3 seconds are spent between line 1294 and 1347.  Probably on line 1306.
But I don't understand how this module interacts with the rest of the program so I'm lost.
are you talking http://hg.mozilla.org/releases/comm-beta/annotate/e9a87fde7574/mailnews/imap/src/nsImapProtocol.cpp#l1294 ?

can you reproduce in *windows* safe mode with networking enabled?
- XP http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/boot_failsafe.mspx

And seamonkey in safe mode?
Flags: needinfo?(pe1chl)
Please read begin of thread.  I already tested safe mode for seamonkey and reported result.
I cannot bring the system up in safe mode, probably due to restrictions in group policies
etc.  I tried it with virus scanner disabled, no difference.
I have installed many versions (working my way back) between 2.20 and 2.14.1 and it
turns out that the problem actually appears in 2.15 and all later versions, and is not
present in 2.14.1 and before.
Flags: needinfo?(pe1chl)
Version: SeaMonkey 2.20 Branch → SeaMonkey 2.15 Branch
To reproduce the issue, the setting "Check for new messages at startup" for all of the
accounts (in "server settings" of the accounts) needs to be ticked.
This sets the .login_at_startup pref for the server.
When this is not enabled, the program comes up much quicker and the delay occurs once the
account is first accessed.
:Irving is better than me for analysing imap stuff like this.
Flags: needinfo?(ludovic)
Flags: needinfo?(irving)
(In reply to Wayne Mery (:wsmwk) from comment #22)
> are you talking
> http://hg.mozilla.org/releases/comm-beta/annotate/e9a87fde7574/mailnews/imap/
> src/nsImapProtocol.cpp#l1294 ?

repeating question above.

also
- which antivirus software do you use?
- are any accounts gmail?
Flags: needinfo?(pe1chl)
Whiteboard: [regression?]
IMAP servers are on local network (comment #4).  Virusscanner is NOD32 (comment #9).
Sourcefile is mailnews/imap/src/nsImapProtocol.cpp from downloaded sources for 2.20 (comment #21).
Please don't clutter the bug with questions that are already answered.
(In reply to Rob Janssen from comment #28)
> IMAP servers are on local network (comment #4).  Virusscanner is NOD32
> (comment #9).
> Sourcefile is mailnews/imap/src/nsImapProtocol.cpp from downloaded sources
> for 2.20 (comment #21).
> Please don't clutter the bug with questions that are already answered.

my question sir, is whether the specific line number, which you will notice is in my URL, points to the source lines you think are causing the problem.

If you want people to help you, please be polite.
My analysis of sourcecode is in comment #21 referring to log messages appearing in comment #19.
I don't know anything more about the source than what is written there.  In particular I do not
know where the problem is.  It probably is not in that module.
Flags: needinfo?(pe1chl)
I did more tests.  First, I tried to setup an account on the Windows system at work where I first noticed
this problem, keeping everything as default as possible.   Starting with no prefs.js and only adding a
single IMAP account using the wizard, the problem is reproducible.  I.e. there is the extra 3-second delay
upon connection of the IMAP server when the program is started with -mail, and the message list is grey
during those 3 seconds.   When "check for new messages at startup" is unchecked, this delay disappears but
it occurs when the INBOX is first clicked.

Second, I also experimented with my Linux system at home (also running 2.20).  When the program is started
with -mail, the GUI appears correct but the "barberpole" pattern appears in the statusbar for 3 seconds
per IMAP server configured.  So while the appearance is different, the underlying phenomenon is the same.
(as I did not see the same greyed GUI appearance and my system has not much memory so startup is slowish
anyway, I first believed the problem did not occur on Linux)
I'm not as familiar with Seamonkey as I am with Thunderbird - does SM support the Gecko Profiler? If so, getting a startup profile would help.

You can get the latest pre-release version of the Profiler add-on from https://github.com/bgirard/Gecko-Profiler-Addon/raw/master/geckoprofiler.xpi (it is much better than the one at addons.mozilla.org), go to Tools/Add-ons, click the gear icon in the upper right and select "install add-on from file" to load the .xpi file into Seamonkey.

Then set the environment variable MOZ_PROFILER_STARTUP=true and run Thunderbird; once the UI is up, click on "dump profile" (in Thunderbird, it's at the bottom right of the main window).

Feel free to look through the profile yourself; if you want one of us to look at it, click on the "share" button at the lower right of the Cleopatra window - this uploads a copy of the profile to a Mozilla server and generates a unique URL you can send us.
Flags: needinfo?(irving)
Testing with a copy of Thunderbird 24 (beta) from about two weeks ago, I can't reproduce the 3 second delay between the "ImapThreadMainLoop entering" and "ProcessCurrentURL: entering" log messages - in my log, they occur within a millisecond.

I'm not set up to do testing on Seamonkey; I work in Thunderbird and Firefox. It does appear that there is something quite predictable causing a 3 second delay between IMAP thread startup and the first URL request sent to that IMAP thread in your environment. At this point, if the Gecko Profiler works that's probably our best bet to pinpoint the cause.
I have tried the geckoprofiler.xpi but it fails to install with the message that it is incompatible
with Seamonkey.  And indeed the install.rdf only has entries for Firefox and Thunderbird.  Would it
be worth a try to just add an entry for Seamonkey in install.rdf or would that be guaranteed to fail?
Yeah, it doesn't work with SeaMonkey because current builds are not instrumented for it (sticks pin in Callek's doll)+need to workaround some hardcoded to Firefox parts...
Given profiler doesn't work on SM, I suggest Rob try to profile the account+server using Thunderbird 24 per comment 32.  If it doesn't reproduce, then at least we know it's probably specific to SM :)  BUt if it does, then we have a profile!
Keywords: perf
Summary: Very slow program startup → Very slow program startup if getting new mail
Ok more test results: this test revealed something that at least explains why I can easily reproduce it while other people can't.
As I wrote before we are on an isolated network with local IMAP servers and proxy server (squid) to internet.
This appears to be crucial, as I found out when configuring Thunderbird.
When no proxy server is configured, it starts quickly.  When I configure a proxy server, as I needed to do to get the profiler results (it connects to a website!), the problem presents itself.
We normally use an automatic proxy config from a local webserver, which uses NTLM auth to determine the user credentials and present a proxy config that allows or disallows certain sites.
However, this is not the problem.  When configuring a static proxy (host and portnumber) the problem is the same.  As long as a proxy is configured, it delays connect to the local IMAP server.

So, it is not specific to SeaMonkey, it occurs in Thunderbird as well.
Ian Neal, do you use a proxy as well?
If it proxy-related, enable NSPR logging (Example - https://wiki.mozilla.org/MailNews:Logging, but use all:4 logging level) and look where delay is happening
Unfortunately the trace does not show particular events related to the proxy.
I have made two traces, the first is with proxy enabled and the second is with proxy disabled.
In both cases the actual connection does not go through the proxy, the server is local.
This is also confirmed by the proxy logs.
However, there still is a 3-second delay when the proxy is enabled.
Looking at the .pac file access log (the proxy autoconfig file) it has been fetched exactly
at the end of the 3-second delay.  The actual fetching of the .pac file takes only 37 milliseconds.
(logged by Apache)
So the question is, what takes 3 seconds when a proxy is configured, before it is actually checked if this proxy should be used for the connection?  Maybe some autodetection going on?
(in earlier tests I traced the network traffic and did not find an outgoing packet at the beginning of the 3 seocnds delay)

with proxy:
2013-09-20 13:23:44.331000 UTC - 0[e0f140]: read -> 27
2013-09-20 13:23:44.331000 UTC - 0[e0f140]: read -> 0
2013-09-20 13:23:44.331000 UTC - 3016[826c580]: ImapThreadMainLoop entering [this=7e45000]
2013-09-20 13:23:44.331000 UTC - 0[e0f140]: 7e45000:mail.uw:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: creating nsSocketTransport @677aa60
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: nsSocketTransport::Init [this=677aa60 host=mail.uw:143 proxy=:0]
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: Reset callbacks for secinfo=0 callbacks=879e0a0
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: nsSocketTransport::OpenInputStream [this=677aa60 flags=1]
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: STS dispatch [82438d8]
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: send: fd=eb3660 osfd=1476 buf=3ae5c1 amount=1
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: send -> 1
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: nsSocketTransport::PostEvent [this=677aa60 type=0 status=0 param=0]
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: STS dispatch [879e0c0]
2013-09-20 13:23:47.331000 UTC - 3688[e0f680]:     ...returned after 3861 milliseconds
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: send: fd=eb3660 osfd=1476 buf=3ae5c1 amount=1
2013-09-20 13:23:47.331000 UTC - 3688[e0f680]: recv: fd=eb3600 osfd=1500 buf=3a4faa4 amount=1024 flags=0
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: send -> 1
2013-09-20 13:23:47.331000 UTC - 0[e0f140]: nsSocketTransport::OpenOutputStream [this=677aa60 flags=1]
2013-09-20 13:23:47.331000 UTC - 3688[e0f680]: recv -> 2, error = 0, os error = 0

without proxy:
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: read -> 27
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: read -> 0
2013-09-20 13:26:52.722000 UTC - 3820[7b6b580]: ImapThreadMainLoop entering [this=8743000]
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: 8743000:mail.uw:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: creating nsSocketTransport @7f36a60
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: nsSocketTransport::Init [this=7f36a60 host=mail.uw:143 proxy=:0]
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: Reset callbacks for secinfo=0 callbacks=86e8ce0
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: nsSocketTransport::OpenInputStream [this=7f36a60 flags=1]
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: STS dispatch [7b499c8]
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: send: fd=eb3660 osfd=1480 buf=3ae5c1 amount=1
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: send -> 1
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: nsSocketTransport::PostEvent [this=7f36a60 type=0 status=0 param=0]
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: STS dispatch [872dfc0]
2013-09-20 13:26:52.722000 UTC - 1488[e0f680]:     ...returned after 912 milliseconds
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: send: fd=eb3660 osfd=1480 buf=3ae5c1 amount=1
2013-09-20 13:26:52.722000 UTC - 1488[e0f680]: recv: fd=eb3600 osfd=1504 buf=3a4faa4 amount=1024 flags=0
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: send -> 1
2013-09-20 13:26:52.722000 UTC - 1488[e0f680]: recv -> 1, error = 0, os error = 0
2013-09-20 13:26:52.722000 UTC - 0[e0f140]: nsSocketTransport::OpenOutputStream [this=7f36a60 flags=1]
2013-09-20 13:26:52.722000 UTC - 1488[e0f680]: nsSocketInputStream::Read [this=7f36b00 count=32768]
In Comment 37 there is an error.  I wrote:
When configuring a static proxy (host and portnumber) the problem is the same.

This turns out to be incorrect.  When the proxy is configured static (host and port), it works OK.
The problem only occurs when the proxy is defined using a mechanism that uses the autoconfig file.
In my case that is true for "autodetect"  (works via wpad.dat), "use system settings" (same), or
when I use the explicitly configured autoconfig URL.

I tried to replace the script using NTLM with a statically served file, and the result was the same.
So the NTLM dialogue (which happens within 40ms anyway) is not the cause of the problem.
When looking through a tree diff between 2.14.1 and 2.15 I see a lot of changes w.r.t. proxy configuration and nsProxyAutoConfig.js
Probably this bug is a side-effect of those changes?
How can I locate the Bugzilla bugnumber that underlies these modifications?
(search did not return it)
Go to http://mxr.mozilla.org/mozilla-central, find needed file(s), open it, press Hg Blame on right, after data loading is finished, find the lines you interested in, open links on left of them, you will get in diff mode, at top you see changeset xxxxx and that changeset id on right, press it and you will get bug number and all other data about that change
Thank you, it appears to be related to Bug 769764 and I have asked there if it could be the cause.
Blocks: 769764
Hi all, after following this thread I checked the proxy settings and that proved to be my problem/solution. 
I use my laptop (Windows 7 64bits) both at home (lan/wifi) and in the office (corporate network with proxy, wired & wifi). When in the office the program aparently auto-detects the proxy and then stays in proxy mode. When starting up at home without any proxy, every account (I have 5) waits for 3 seconds,  looking for the proxy server I asume. Thus it takes 15 idle seconds before the program fully starts up.

I've just reset to 'no proxy' and now startup takes about 2 seconds.
Yes, I already nailed it down to that particular issue with the auto proxy config.
(after spending lots of time and effort on many different tests)
Now we only have to hope that a small patch or another workaround is possible.
Unfortunately we never heard from the proxy people in bug 769764.
Summary: Very slow program startup if getting new mail → Very slow program startup if getting new mail. proxy related
should this move to mailnews core?
Flags: needinfo?(philip.chee)
Flags: needinfo?(mbanner)
(In reply to Wayne Mery (:wsmwk) from comment #48)
> should this move to mailnews core?

Yes.
Component: General → Backend
Product: SeaMonkey → MailNews Core
Version: SeaMonkey 2.15 Branch → 18
William Winston

From original report to Wayne, and Wayne's response -- no issue with proxies.  I did, however, try a re-install TBird 24, to no avail; the bug still was bugging.  In the meantime, I visited the Genius Bar at local store and learned the following: (1) Re-set Power Manager; (2) Repair Permissions; (3) Re-start from Lion Recovery Partition, and use Terminal to Reset User Password, Permissions and ACL.  I followed those instructions, but did not reinstall the whole 10.7.5 System from Recovery -- waiting on that.  No improvement with TBird, although those procedures seemed to speed-up my iMac start-up process and opening of all other applications.  A couple of days later, this week, I deleted TBird 24 with AppCleaner, then went in manually to my TBird User folder to clear out old Crash Reports and Accounts that I had previously deleted (which still showed artifacts).  Then I re-installed TBird 24 -- still the start-up bug, after all that other work.  So I uninstalled 24 and installed 17.0.8, which works without a hitch, as before.
Flags: needinfo?(philip.chee)
Flags: needinfo?(mbanner)
Is there any possibility to have a small patch or workaround for this issue that is preventing me from
upgrading past seamonkey 2.14.1?
We now have other issues and would like to update to a more recent version, but this issue has to be solved.
Maybe it is possible to disable the proxy support for only the IMAP protocol?
(we need proxy only for web access, not for access to the IMAP server which is local)
Are you getting close to a fix for this? It's been 4 months now since the first comment was posted above reporting the problem!
(In reply to Phoenix from comment #53)
> I wonder if Bug 923458 helps here too, can you check current nightly builds?
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-
> trunk/seamonkey-2.25a1.en-US.win32.zip

Yes, it appears it has been fixed in that build.  Unfortunately another problem was introduced in
seamonkey in the meantime so we cannot switch just yet.  Is there a simple patch we can apply to
e.g. the 2.20 release to backport the fix to that version?  (replace some file, change some js, whatever)
Flags: needinfo?(pe1chl)
The patch is in a .cpp file:
https://hg.mozilla.org/mozilla-central/rev/cc9c2520a53e

which means that at the very least you would need to compile a version of SeaMonkey 2.20 with that patch applied to the source code.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(mortonspam)
Resolution: --- → DUPLICATE
What I'm seeing, in my Users Library folder, is that in a Mozilla folder I have a whole set of profiles, supporting files, etc. in a Mozilla folder, which pertain to an old Thunderbird account with old server settings. Then I also have a Thunderbird folder, also in my Users Library,which has the current and correct profile and server settings, mailboxes, etc.  And in the Application Support folder, I have a Mozilla folder inside of which is an Extensions folder, inside of which is another folder named "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}".  Are these multiple folders, sets of profiles, causing the stall on Thunderbird start-up?  What next?
Flags: needinfo?
>  Are these multiple folders, sets of profiles, causing the stall on Thunderbird start-up?  
unlikely

> What next?
bug 923458 patch came with Thunderbird version 31. If you still see a problem using acurrent version of Thunderbird in please file a  new bug report
Flags: needinfo?
You need to log in before you can comment on or make changes to this bug.