+++ This bug was initially created as a clone of Bug #493000 +++

This bug is happening on RHEL6 beta. In my case, my IMAP server is hosted at
the same machine where I'm running thunderbird, and it has about 11 Gb of size. 
I even tried to play with some configurations to disable cache, remove all
extensions, run on safe mode, etc.

Even if I start thunderbird with the server daemon stopped, it keeps unresponsive (or almost unresponsive) after a while, and the process doesn't stop.

That's the version of the Thunderbird I'm running:
   thunderbird-3.0.4-2.el6.i686

The server is running Dovecot, using the atrpms package for RHEL6:
   dovecot-1.2.11-3_108.el5_89.i686

Description of problem:
Since upgrading to thunderbird 3 beta my x86_64 WS. is having semi long periods of 100% cpu usage.  My i686 laptop with the same setup does not show this.

I have two IMAP accounts, both woth several Gigabyte of mail in multiple folders, some with a few hundred thousand messages.

Automatich check for new messages is turned OFF for both accounts, and junk filter in thunderbird is disabled.

I even tried to rm -Rf the thunderbird profile-folder and set up the accounts from scrath, but the problem persists.
As mentioned this only happens on x86_64 and was not an issue with Thunderbird 2 (I downgraded to the latest Thunderbird 2 package to check, and the problem disappeared).



Version-Release number of selected component (if applicable):
thunderbird-3.0-2.1.beta2.fc11.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Run thunderbird (v3 beta)
2.
3.
  
Actual results:
Every 10-15 minutes thunderbird freezes and cpu usage peaks at 100% for 2-3 minutes.


Expected results:
Thunderbird should run smooth all the time

Additional info:

--- Additional comment from mcepl on 2009-03-31 07:12:05 EDT ---

Hmm, I am exactly the same configuration here and cannot reproduce it. Is there something more which could help us to reproduce it here. For example, which filesystem you use for your /home directory?

--- Additional comment from redhat on 2009-03-31 07:20:13 EDT ---

/home is actually on NFS, but that is the same for both the (i686) laptop and the (x86_64) workstation.

To be sure NFS is not the problem I have moved the profile from $HOME/.thunderbird/ to a local filesystem and added a symlink:

lrwxrwxrwx. 1 olen olen 42 2007-09-17 19:34 .thunderbird/gwagla2i.jobb -> /var/cache/olen/thunderbird/gwagla2i.jobb/

/var/cache is part of / which is LVM with ext3

$ df /var/cache/olen/thunderbird/gwagla2i.jobb/
Filesystem                        1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00   149248172  35944648 105599768  26% /

When stracing the process I can't see anything special, but please let me know if there is anything else I can do to debug this.

--- Additional comment from mcepl on 2009-03-31 07:33:36 EDT ---

First of all, could we get output of the command

	rpm -qa *xulrun* *thunderbird* *mozilla* *flash* *plugin*

Please also install thunderbird-debuginfo (debuginfo-install is from
yum-utils package).

	debuginfo-install thunderbird

Then run thunderbird and connect to it with gdb by command

gdb --pid=$(pidof thunderbird-bin)

Then make thunderbird work again with command

   (gdb) cont
   
and do whatever you did to make thunderbird freeze. When it happens, you should go back to the gdb and run

	(gdb) thread apply all backtrace

This produces usually many screens of the text. Copy all of them into a text editor and attach the file to the bug as an uncompressed attachment.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

--- Additional comment from redhat on 2009-03-31 07:47:12 EDT ---

Here is the rpm -qa -output. Attaching gdb-output as soon as I have it:

#  rpm -qa *xulrun* *thunderbird* *mozilla* *flash* *plugin*
PackageKit-yum-plugin-0.4.6-0.3.20090324git.fc11.x86_64
plymouth-plugin-spinfinity-0.7.0-0.2009.03.10.2.fc11.x86_64
gstreamer-plugins-base-0.10.22-2.fc11.x86_64
mozilla-filesystem-1.9-4.fc11.x86_64
nspluginwrapper-1.3.0-5.fc11.x86_64
plymouth-plugin-label-0.7.0-0.2009.03.10.2.fc11.x86_64
alsa-plugins-pulseaudio-1.0.18-3.fc11.x86_64
setroubleshoot-plugins-2.0.14-2.fc11.noarch
yum-plugin-refresh-updatesd-1.1.21-2.fc11.noarch
gutenprint-plugin-5.2.3-5.fc11.x86_64
xulrunner-1.9.1-0.11.beta3.fc11.x86_64
xfce4-mailwatch-plugin-1.1.0-3.fc11.x86_64
gstreamer-plugins-good-0.10.14-2.fc11.x86_64
gstreamer-plugins-farsight-0.12.10-2.fc11.x86_64
plymouth-plugin-pulser-0.7.0-0.2009.03.10.2.fc11.x86_64
yum-plugin-fastestmirror-1.1.21-2.fc11.noarch
anaconda-yum-plugins-1.0-4.fc11.noarch
PackageKit-gstreamer-plugin-0.4.6-0.3.20090324git.fc11.x86_64
plymouth-plugin-solar-0.7.0-0.2009.03.10.2.fc11.x86_64
plymouth-plugin-fade-in-0.7.0-0.2009.03.10.2.fc11.x86_64

--- Additional comment from redhat on 2009-03-31 07:56:15 EDT ---

Sorry, missed the thunderbird-packages from the above list:

thunderbird-3.0-2.1.beta2.fc11.x86_64
thunderbird-debuginfo-3.0-2.1.beta2.fc11.x86_64

--- Additional comment from redhat on 2009-03-31 08:03:10 EDT ---

Created an attachment (id=337291)
backtrace of frozen thunderbird

--- Additional comment from redhat on 2009-03-31 08:24:53 EDT ---

Created an attachment (id=337295)
Another backtrace from the next freeze

--- Additional comment from stransky on 2009-03-31 08:37:16 EDT ---

Hm, seems to be in:

Thread 1 (Thread 0x7f9d20082800 (LWP 27790)):
#0  0x00007f9d096ab010 in IndexOf<unsigned int, nsDefaultComparator<unsigned int, unsigned int> > (comp=<value optimized out>, start=<value optimized out>, item=<value optimized out>, 
    this=<value optimized out>) at ../../../mozilla/dist/include/xpcom/nsTArray.h:393
#1  IndexOf<unsigned int> (comp=<value optimized out>, start=<value optimized out>, item=<value optimized out>, this=<value optimized out>) at ../../../mozilla/dist/include/xpcom/nsTArray.h:407
#2  Contains<unsigned int> (comp=<value optimized out>, start=<value optimized out>, item=<value optimized out>, this=<value optimized out>) at ../../../mozilla/dist/include/xpcom/nsTArray.h:379
#3  nsAutoSyncState::PlaceIntoDownloadQ (comp=<value optimized out>, start=<value optimized out>, item=<value optimized out>, this=<value optimized out>)
    at /usr/src/debug/thunderbird-3.0/mailnews/imap/src/nsAutoSyncState.cpp:165
#4  0x00007f9d0966885f in nsImapMailFolder::HeaderFetchCompleted (this=0x7f9d046f8c00, aProtocol=0x7f9cad8b8000) at /usr/src/debug/thunderbird-3.0/mailnews/imap/src/nsImapMailFolder.cpp:5181
#5  0x00007f9d1f34b46d in NS_InvokeByIndex_P (that=0x4efcd, methodIndex=2773706040, paramCount=31457288, params=0x7f9d02051e78)
    at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_linux.cpp:208
#6  0x00007f9d1f343de3 in nsProxyObjectCallInfo::Run (this=0x7f9caceb4640) at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/proxy/src/nsProxyEvent.cpp:181
#7  0x00007f9d1f33fab1 in nsThread::ProcessNextEvent (this=0x7f9d1c54c280, mayWait=1, result=0x7fff280b858c) at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/threads/nsThread.cpp:510
#8  0x00007f9d1f310984 in NS_ProcessNextEvent_P (thread=0x4efcd, mayWait=-1521261256) at nsThreadUtils.cpp:227
#9  0x00007f9d0dbc75c9 in nsBaseAppShell::Run (this=0x7f9d07d6ac40) at /usr/src/debug/thunderbird-3.0/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170
#10 0x00007f9d0cf308a2 in nsAppStartup::Run (this=0x7f9d07c5f900) at /usr/src/debug/thunderbird-3.0/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:192
#11 0x00007f9d1f7b25ca in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>) at /usr/src/debug/thunderbird-3.0/mozilla/toolkit/xre/nsAppRunner.cpp:3279
#12 0x00000000004019bc in main (argc=1, argv=0x7fff280b8dc8) at /usr/src/debug/thunderbird-3.0/mail/app/nsMailApp.cpp:103

So it looks like issue with nsImapMailFolder::HeaderFetchCompleted() from nsAutoSyncState. We may find an upstream bug for that or file a new one.

--- Additional comment from redhat on 2009-03-31 09:15:11 EDT ---

One thing I forgot to mention is that i use ssl/tls on the IMAP accounts.
It might not be related at all, but might be worth mentioning if it has to do with fetching the headers.

--- Additional comment from drepper on 2009-04-11 05:49:23 EDT ---

Pretty much the same situation here and I see the same problem.

When this happens th memory use of thunderbird shoots up.  After startup it's about 650M.  During the 100% CPU time it shoots up to 1.6G, to go down after that.

--- Additional comment from mcepl on 2009-04-14 06:55:10 EDT ---

Hmm, could it be related to https://bugzilla.mozilla.org/show_bug.cgi?id=472019 ?

--- Additional comment from drepper on 2009-04-14 09:56:49 EDT ---

(In reply to comment #11)
> Hmm, could it be related to https://bugzilla.mozilla.org/show_bug.cgi?id=472019
> ?  

Doesn't look like it.  This is no crash.  My guess is that it's just periodically doing unnecessarily much work.  Copying things around into freshly allocated memory etc.

--- Additional comment from drepper on 2009-04-21 21:35:42 EDT ---

Haven't there been any changes in the upstream thunderbird so that we could just have a new build from cvs?  This bug is really crippling.  Every 30 secs of writing is followed by 2 to 2.5 minutes of freezing.

--- Additional comment from stransky on 2009-05-04 10:19:15 EDT ---

I'm just installing beta2 to my 64-bit box so let's see if I can catch it there...

--- Additional comment from redhat-bugzilla on 2009-05-11 20:36:21 EDT ---

I am running rawhide on a x86_64 box. The version below is what I am using. This is bad enough that I think that the package should be downgraded to 2.0.x. One error I got was a this script is taking too long for folderpane.js. My e-mail client is now dependent on javascript code?!?!?

thunderbird-3.0-2.1.beta2.fc11.x86_64

What is up with the tabs? There doesn't seem to be a way to open a new one, but yet I have a tab bar.

--- Additional comment from redhat-bugzilla on 2009-05-12 13:49:21 EDT ---

  I tried switching to the i586 version below on my x86_64 box to see if it would help. It seems to be just as bad. I just switch folders or sometimes scroll in the current folder and the whole interface will freeze for a number of seconds while it eats 100% of a core.

thunderbird-3.0-2.1.beta2.fc11.i586

--- Additional comment from redhat-bugzilla on 2009-05-12 14:22:33 EDT ---

  I turned off the sync feature on all my accounts. Just turned the feature off and on causes freezes.

Edit | Account Settings | "Account" | Syncing & Disk Space | Keep messages for this account on this computer

--- Additional comment from redhat-bugzilla on 2009-05-12 17:05:46 EDT ---

  Probably related to this upstream bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=442674

--- Additional comment from redhat-bugzilla on 2009-05-22 03:33:40 EDT ---

I started to see this again with sync off. I started getting a crazy amount of spam, and ended up with 300,000+ messages in one folder. I received the same folderpane.js script error. Thunderbird also managed to cause a OOM event.

Out of memory: kill process 16440 (thunderbird-bin) score 793324 or a child
Killed process 16440 (thunderbird-bin)

--- Additional comment from fedora-triage-list on 2009-06-09 08:50:08 EDT ---


This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from milan.kerslager on 2009-06-12 03:04:07 EDT ---

thunderbird-3.0-2.3.beta2.fc11.x86_64 freezes sometimes here too (F11 + updates)

--- Additional comment from redhat on 2009-06-12 03:14:50 EDT ---

The problem seems to be fixed with
thunderbird-3.0-2.4.b3pre.hg.6a6386c16e98.fc11.x86_64 from koji.

Have been running that for a few weeks now without any trouble.

Rgds.

--- Additional comment from holler on 2009-06-17 04:05:52 EDT ---

That version from koji doesn't help here (and has no locales).

Thunderbird still constantly tortures my hard disk (and I have the synchronization turned off).

Thunderbird 3 on F11 is currently just unusable (at least with imap).

--- Additional comment from holler on 2009-06-18 07:21:47 EDT ---

It seems the hard disk activitiy with beta3pre was because the beta3pre has fetched and stored about 1 GB from my imap-server for which it has needed some time (because it seems to have lost a large part of the headers during upgrade to 3.0b2 because of bug 505884).

Actual the beta3pre behaves like it should, just that 1 GB in .thunderbird isn't what I'm using IMAP for (I have synchronization turned off).

Thunderbird 2 uses less than 300 MB in .thunderbird, which is just enough for the headers of about 4.5 GB mails which my imap-server actual has stored (uncompressed).

--- Additional comment from aaron.toponce on 2009-07-16 11:34:27 EDT ---

I am confirming high usage of CPU usage. It appears to be from several processes running. Further, if it sits for several hours, it has effectively chewed through 1GB of RAM, and begins swapping. I do have a massive IMAP account, with tens of thousands of messages taking up roughly 2GB. If you don't have enough info, I can provide any debugging data that would provide useful. Currently running TB 3 Beta 2.

--- Additional comment from bertho.dk on 2009-07-28 05:23:30 EDT ---

I also noted the same 100% CPU problem after just upgrading to F11. However, it seems that the CPU usage is related to the number of mails in the folder and/or the number of unread mails.

After going through all folders and marking some 50000 messages as read and splitting some large folders, I now see the CPU usage being reduced significantly to a point where thunderbird is usable again. I still see spikes of CPU usage, which are probably from the inbox.

--- Additional comment from milan.kerslager on 2009-08-06 04:31:13 EDT ---

thunderbird-3.0-2.3.beta2.fc11.x86_64 spins and "freezes" with this ltrace output (too many same rolling lines, Thunderbird is in R state, eating 100% CPU, impossible to switch focus on it):

pthread_mutex_unlock(0x7fd3e5b8f040, 0xf0000000, 0x7fd3c7ac6000, 27, 0xf8000000)                 = 0
pthread_mutex_lock(0x7fd3e5b8f040, 88, 6, 0x7fff1a76a004, 88)                                    = 0
pthread_mutex_unlock(0x7fd3e5b8f040, 0xe0000000, 0x7fd3c7ac6000, 28, 0xf0000000)                 = 0
pthread_mutex_lock(0x7fd3e5b8f040, 88, 6, 4, 0)                                                  = 0
pthread_mutex_unlock(0x7fd3e5b8f040, 0xc0000000, 0x7fd3c7ac6000, 29, 0xe0000000)                 = 0
pthread_mutex_lock(0x7fd3e5b8f040, 88, 6, 0x7fff1a76a004, 88)                                    = 0
pthread_mutex_unlock(0x7fd3e5b8f040, 0x80000000, 0x7fd3c7ac6000, 30, 0xc0000000)                 = 0
pthread_mutex_lock(0x7fd3e5b8f040, 88, 6, 4, 0)                                                  = 0
pthread_mutex_unlock(0x7fd3e5b8f040, 0, 0x7fd3c7ac6000, 31, 0x80000000)                          = 0
pthread_mutex_lock(0x7fd3e5b8f040, 88, 6, 0x7fff1a76a004, 88)                                    = 0
pthread_mutex_unlock(0x7fd3e5b8f040, 1022, 0x7fd3c7ac6000, 0, 1023)                              = 0
pthread_mutex_lock(0x7fd3e5b8f040, 88, 6, 4, 0)                                                  = 0
pthread_mutex_unlock(0x7fd3e5b8f040, 1020, 0x7fd3c7ac6000, 1, 1022)                              = 0
pthread_mutex_lock(0x7fd3e5b8f040, 88, 6, 0x7fff1a76a004, 88)                                    = 0

--- Additional comment from mcepl on 2009-08-06 10:08:22 EDT ---

*** Bug 513783 has been marked as a duplicate of this bug. ***

--- Additional comment from mike.cloaked on 2009-08-20 16:40:48 EDT ---

I don't know if my symptoms are related but whilst TB is running CPU usage seems OK, but as soon as I close TB then there is a process "thunderbird-bin" that sits there consuming around 56% of the CPU. This is consistent - I connect to an external imap server and have lightning installed but I doubt if this is relevant.

This is for an up to date F11 system running on an NC10 netbook.

--- Additional comment from milan.kerslager on 2009-09-05 14:04:36 EDT ---

I have thunderbird-3.0-2.6.b3.fc11.x86_64 since Aug 17 (regular F11 update), but still have troubles with freezing. I have GNOME with standard settings.

--- Additional comment from mike.cloaked on 2009-09-29 15:14:26 EDT ---

I am running TB 3.0beta4 for the i386 version from updates-testing in F11 and this problem has been resolved for me with this build.  However I am aware that there are significant problems with the x86_64 version - I understand that there is no official x86_64 version due to the developers believing that there are unresolved problems that will make that version not work. I wonder if installing the 32 bit version of TB, and running in an x86_64 OS will see the problems disappear?

--- Additional comment from milan.kerslager on 2009-09-30 05:50:07 EDT ---

With 64bit up-to-date Fedora 11 I tryed i586 package (thunderbird-3.0-2.6.b3.fc11.i586). If freezes like 64bit version.

--- Additional comment from urkle on 2009-10-12 12:06:08 EDT ---

the 64bit version of beta4 still freezes quite often.. (actually seems to be more often than in beta3).

I have to let it sit there for sometimes up to 5 minutes before I'll regain control of the application.  (this is a quad core 2.6Ghz phenom w/ 4GB of ram)

--- Additional comment from bill-bugzilla.redhat.com on 2010-04-21 13:20:34 EDT ---

I see this with:

  thunderbird-3.0.4-1.fc12.x86_64

so I'm looking here to see that it's being tracked properly.  I'm not sure we've gotten past symptoms to cause here yet.

upstream 472019 is marked as the external bug but that's about crashes.

Nathan suggests upstream 442674 as relevant which is marked incomplete due to lack of feedback.

I did a quick search on some of the symbols in Martin's backtrace but didn't turn up likely candidates.

I'll try attaching with gdb next time I see the symptom.

--- Additional comment from bill-bugzilla.redhat.com on 2010-04-22 23:53:08 EDT ---

So, on mine anyway, it was thrashing .msf files which are mork databases.  I filed bmo 561272 on it.

One thing that helped was rebuilding index files.  Roughly, if your thunderbird is hung for the same reason:

  strace -p `pidof thunderbird-bin`

you'll see:

  lseek(119, 235773952, SEEK_SET)         = 235773952
  read(119, "^90=c9aab)(^92=0)(^91=0)(^93=0)("..., 4096) = 4096
  read(119, ")(^92=0)(^91=0)(^93=0)(^94=0)]\n["..., 4096) = 4096

ad. nauseum, but ctrl-c it and note that first number (file descriptor) and:

  ls -l /proc/`pidof thunderbird-bin`/fd/119

which will show you which folder's .msf is being thrashed.  When the UI comes back you can right-click the folder's Properties... and click 'Rebuild Index'.  I had one .msf go from 249MB to 2K.  Mork databases are apparently all loaded into memory and parsed before they're used.  If they're big ... ouch.  Efforts to replace Mork in Thunderbird appear to have begun in the last century.  Originally talked about for a 3.0 conversion to sqllite, it appears nothing's been done since 2008 on it so we might be with this problem a while (if my problem is the same as others').

--- Additional comment from fedora-triage-list on 2010-04-27 09:22:38 EDT ---


This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from bill-bugzilla.redhat.com on 2010-04-27 16:57:40 EDT ---

Reporter/maintainer: please bump to f12.