Closed Bug 364795 Opened 18 years ago Closed 14 years ago

Hourglass on folders window after msg "Unable to load [...] history.mab [...]" after update to TB 1.5.0.9

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: paolo, Unassigned)

References

(
URL
)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Build Identifier: Thunderbird version 1.5.0.9 (20061207)

(this is a summary of a couple of messages at http://forums.mozillazine.org/viewtopic.php?t=502234)

I get the following message at some point in the session:

"Unable to load address book file history.mab. It may be read-only, or locked by another application. Please try again later."

After that point, when I click on another folder to view, I get the hourglass and nothing happens.

Workaround: close Thunderbird and reopen it.

Notice that sending messages still works even if all folders are unaccessible because of the hourglass.

Sometimes lots of old messages are marked as unread after the restart and indexes have to be rebuilt.

I'm marking this bug as critical because the program kind of hangs and it's an extremely annoying bug that makes me think about switching to another mail client if it doesn't get fixed quickly.

Reproducible: Sometimes

Steps to Reproduce:
1. Create a new mail message
2. The popup with the error message appears most of the times.
3. When it appears, click on any folder to get the hourglass. It doesn't necessarily happen on the first one.
do you have any virus checkers or extensions installed that might be locking files? I have never seen this myself...
The only extension I have in Thunderbird is the default Talkback one.
I'm using Norton as antivirus, complemented with Spybot Search and Destroy and WinXP Firewall.
This bug didn't exist in version 1.5.0.8 and the rest of the environment didn't change.
The version number of TB changed, as well as the executable, which could be sufficient for Norton or Spybot to behave differently. I'm not saying that's the cause, but it's theoretically possible.
I've also run into this problem after installing the latest Thunderbird build (1.5.0.9)
(In reply to comment #1)
> do you have any virus checkers or extensions installed that might be locking
> files? I have never seen this myself...
> 

I have also run into this problem, and reported it on Mozillazine.

I just reproduced it by starting a new message. When I type in a To: address, I get the same error dialog. I dismiss it, and then when I go back to T-Bird and click on any folder, the message list is empty, the cursor turns to hourglass, and the preview pane is empty. And that's how it stays.

I have Grisoft's AVG installed, and have never had a problem since the first release of Thunderbird.

Aviad, if you look in your user profile dir, are all the .msf files 0 bytes?

Is there anything special about the hardware you're running, like dual cpu's? The fact that all folders suddenly become un-openable (until restart?) is very odd, along with the address book suddenly becoming un-openable. As I've said before, since the .msf files and address book code is separate, the fact that both stop working implies something external is acting on the files.

If you look in the task manager, I suppose there's only one copy of Thunderbird/Seamonkey running?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #6)
> Aviad, if you look in your user profile dir, are all the .msf files 0 bytes?

MSF files are not 0 bytes, they vary from 2KB to 3MB...

> Is there anything special about the hardware you're running, like dual cpu's?

Nothing special. AMD Athlon 64 processor. 1GB Memory. Win XP Media Center Edition SP2.

> The fact that all folders suddenly become un-openable (until restart?) is very
> odd, along with the address book suddenly becoming un-openable. As I've said
> before, since the .msf files and address book code is separate, the fact that
> both stop working implies something external is acting on the files.

Double-clicking on the inbox does pop up another instance and shows the messages and preview pane, but this doesn't work for other folders, and single-clicking to change folders (even in the new instance) doesn't work. I can also go ahead and compose a message, and the addresses DO show up in a pull-down on the To: line. I can successfully send the message.
 
> If you look in the task manager, I suppose there's only one copy of
> Thunderbird/Seamonkey running?
> 

Yes, only one instance of Thunderbird running (using 106,416K of memory!!!).


64 bit processor is not that normal :-)

So most of the time you compose a message, you get that address book error? Can you try making a backup of your address book, then, export it to ldif, clear it out, and then re-import from ldif? This is just a wild guess, but perhaps some sort of AB corruption is causing some weird problems. Or you could try temporarily clearing out your AB, after making a backup, and see if you get that address book error even with an empty address book.


Same problem...

WinXP SP2
McAfee VirusScan Enterprise 8.0.0
TB 1.5.0.9 (20061207) [with some extensions]

I can't seem to reproduce the problem at will, seems to occur fairly randomly, but with some frequency...

- send an email, get error message "Unable to load address book file history.mab. It may be read-only, or locked by another application. Please try again later."

- click on one particular folder [my problem seems to only happen with one folder], then hourglass kicks in and have to close TB

- on restart, when i click on said folder, TB tells me its rebuilding the file summary (or something along those lines) and then all my messages come back, but with different sorting.

I've tried cleaing the problematic folder, compacting it, etc., but no luck.  Looking here though would imply this is a problem with the latest release.  I'm going to revert to 1.5.0.8 for the meantime, as I didn't have any of these problems, but I do hope they get sorted quickly.

Many thanks to all of you who make mozilla products possible!!!


(In reply to comment #7)
> (In reply to comment #6)
> > Aviad, if you look in your user profile dir, are all the .msf files 0 bytes?
> 
> MSF files are not 0 bytes, they vary from 2KB to 3MB...
> 
> > Is there anything special about the hardware you're running, like dual cpu's?
> 
> Nothing special. AMD Athlon 64 processor. 1GB Memory. Win XP Media Center
> Edition SP2.
> 
> > The fact that all folders suddenly become un-openable (until restart?) is very
> > odd, along with the address book suddenly becoming un-openable. As I've said
> > before, since the .msf files and address book code is separate, the fact that
> > both stop working implies something external is acting on the files.
> 
> Double-clicking on the inbox does pop up another instance and shows the
> messages and preview pane, but this doesn't work for other folders, and
> single-clicking to change folders (even in the new instance) doesn't work. I
> can also go ahead and compose a message, and the addresses DO show up in a
> pull-down on the To: line. I can successfully send the message.
> 
> > If you look in the task manager, I suppose there's only one copy of
> > Thunderbird/Seamonkey running?
> > 
> 
> Yes, only one instance of Thunderbird running (using 106,416K of memory!!!).
> 

I can report identical problems to the one Aviad has. My hardware configuration is different (dual Centrino 2.33GHz, 3MB RAM). I'm wondering if this is all related to having Norton running in the background (in my case Norton SystemWorks 2005).
Daniel
(In reply to comment #10)
I'm wondering if this is all
> related to having Norton running in the background (in my case Norton
> SystemWorks 2005).
> Daniel
> 
Daniel - I have no Norton products running on my machine, but similar problems, so I doubt it's Norton.  There are a few similar posts in various the mozillazine forums, so I suspect there's something gone amiss with 1.5.0.9.


Same problem here, I run Avast Home antivirus, and NO desktop search software which are notorious for locking files. I also ran Unlocker on the abook files and it doesn't show any applications locking the 2 files.

Like all other reports, this all started for me with 1.5.0.9, all was fine with 1.5.0.8 and before. Lookst like 1.5.0.10 is needed badly for a few of us.

I also opened a bug before seeing this bug, one of them can become a duplicate:

https://bugzilla.mozilla.org/show_bug.cgi?id=364929
Could this have anything to do with the memory leak reported here?

http://forums.mozillazine.org/viewtopic.php?t=503361
it's possible that the memory leak might be related...
I'm running WinXP Pro version 2002 SP2 on a Intel Core 2 T7200 CPU (Centrino).
The problem disappeared when I reverted to 1.5.0.8.
I didn't notice any anomaly in memory consumption with 1.5.0.9 but I have plenty of RAM left and I had to restart Thunderbird after sending each mail, so there was no way for the memory leak to become noticeable.

The locking problem seems to hit only a few users so I understand that it could be difficult to track down. Let me know if there is any way I can help you guys (testing tentative patches, etc.)
I looked around for pre-release 1.5.0.9 builds - this is the oldest one I could find. It has most of the changes that went into 1.5.0.9, but I believe it's still has the 1.5.0.8 version. It would be interesting to know if this build has the bug or not. If it doesn't, it would be interesting to try newer 1.8.0 builds from the parent directory.

ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2006-11-26-08-mozilla1.8.0
(In reply to comment #16)

I have been running version 2 beta 1 for 24 hours without any problem. In particular it seems that this bug has disappeared.

Daniel
For those who are having this problem: could you please keep an eye on the TB process memory usage when the error occurs? When I start TB it takes about 30MB and after this error occurs the process is about 150MB. There's a memory leak here and I don't know if it's related to this issue or not.
Version: unspecified → 1.5
I installed the 26-Nov version over 1.5.0.9 and the problem disappeared.
I installed the 29-Nov over the 26-Nov one and still didn't get the problem. That made me suspect that at that point the official release wouldn't show the problem again and so it was: I installed 1.5.0.9 and all worked fine.
I thought that the installation method could make the difference but it seems it doesn't: I reinstalled 1.5.0.8 and upgraded to 1.5.0.9 by means of Check Updates and the bug didn't appear.
It seems that my system is fixed now but I don't know what fixed it.
I take a guess but I don't know exactly what I writing about so forgive me for any nonsense: could it be that some setup.exe releases locks on files and some other doesn't?
we don't have locks that survive shutting down the app, and/or rebooting. It's very interesting that re-installing fixed this - Can other folks try the same thing, and see if the problem goes away?
Is there a "proper" way to downgrade? I tried installing 1.5.0.8 over my problematic 1.5.0.9, and the problem didn't go away. Then reinstalling 1.5.0.9 didn't help either.

How should I revert to 1.5.0.8 once I've installed 1.5.0.9?
I'm sure others are more expert than I am in this - but you could completely delete your 1.5.0.8/9 Thunderbird program directory (but *not* your user profile directory) and then re-install .08 or .09 - it sounds like if the problem didn't go away after installing 1.5.0.8, then either the re-install didn't work (what does help | about say?) or else the problem really doesn't have to do with 1.5.0.9 per se, but with some strange install problem.
I tried re-installing 1.5.0.9 after removing the directory where the upgrade from .8 to .9 happened but still using the same profile and the problem is still there.

Also to mention it again, 1.5.0.9 seems to be leaking memory like crazy for me, it starts at around 30MB and after an hour the process is at 95MB now. When it gets to about 150MB that's when I usually see the abook problem.

what happens if you do that process but install 1.5.0.8?

I've noticed that 1.5.0.9 seems to leak/bloat a bit of memory, but it's not nearly as dramatic as what you're describing.
I suspect it's the RSS feeds, I have quite a few of them and some are broken in the sense that the server doesn't respond when TB checks for new articles, etc.

I removed all my RSS feeds (I backed up the profile first, of course) and now when TB starts it's only 15MB, compared to 30MB before.

I will keep an eye on the process size without any RSS feeds. So far, it seems to stay constant, though it's a little too early to tell. If after a few hours the process doesn't bloat and I don't see the abook problem, then we may have our answer ...

It would be useful for the others who experience the abook problem to post what their setup is. I have set up:

- 2 IMAP accounts
- 6 newsgroups (all on the same server)
- about 30 RSS feeds

I have the IMAP set to check for new mail every 2 min. and the RSS and newsgroups every 15 min. I think I've read some speculation in the mozillazine.org  forums that check for new messages/RSS articles causes memory leaks if the check is not successful (e.g. server down, etc.) My frequent check for new RSS articles (every 15 min.) and I know I have some feeds that are sometimes down could be the cause for the excessive memory bloat. I'll keep an eye on it and report back.
hmm, interesting - I can look at the rss code - it's mostly in js, so I'd think that most things get garbage collected. But maybe somehow we're chewing up windows resources.
The memory leak has slowed down a lot without any of my RSS feeds. After about 3 hrs, the process is only 28MB and I have not seen the abook error yet.

There's another report in the forums that it *may* occur on checking and downloading mail, so it may not be specific to RSS feeds.

Personally, I'm reverting back to 1.5.0.8 as I cannot afford an unstable mail client. Hopefully 1.5.0.9 didn't do something to my profile that will now trigger the same behavior even in 1.5.0.8 I will do a clean 1.5.0.8 install.
Tim, are you fairly confident that the rss feeds were the issue? I.e., was 3 hours usually sufficient to see the problem before?
Tim, if you could e-mail me a few of your invalid feed urls, I could try that here...
I'd say it's one of the existing memory leaks. With all RSS feeds, after about 1 hr the process size would be around 90MB (from 30MB on start). Even without any RSS feeds, there still seems to be a leak as the process grew from 15MB to 28MB in 3 hours.

See this thread also:

http://forums.mozillazine.org/viewtopic.php?p=2671585

I'm back to 1.5.0.8 and I will keep an eye on its memory usage with all my RSS feeds.

I also still have a 1.5.0.9 upgrade on another computer which only has 4 RSS feeds, 2 IMAP accounts and about 20 newsgroups. That process seems to be leaking memory too, though a lot slower (it's about 40MB from 20MB on start, after about 6 hours).

I'm not sure whether I'm reading the memory usage correctly, I use the "VM Size" value as reported by Windows XP's Task Manager.
(In reply to comment #29)
> Tim, if you could e-mail me a few of your invalid feed urls, I could try that
> here...

I sent you an export of my TB feeds.
unfortunately I can't afford an unstable email system right now, so have reverted back to 1.5.0.8. just to say that I did a straight install of 1.5.0.8 over 1.5.0.9 and the bug is gone for me.  afraid i can't comment on the memory leak aspect, as I never noticed this when I had 0.9 up... doesn't seem to be a problem with 0.8.

btw - my TB only runs 1 pop3 account, no rss feeds or newsgroups via TB.
One thing I notice with Tim's feeds is that I end up with quite a few http connections left open after checking the rss feeds for new messages. I don't think that was happening with my feeds, but I'd have to check. If we're leaking http connections, that could cause grief. Repeatedly hitting get new messages doesn't, however, increase the number of connections left open...
I had the abook problem only once, at 137 MB of RAM (it's 39 MB now)
I have two POP3 accounts, no automatic check of mail, no RSS feed.

By the way, I thought that history.mab problem was gone after a couple of days with no malfunctions (see comment #19) but it appeared again a few hours ago. Again, RAM usage was in the 130-140 MB range.

I reverted to 1.5.0.8 and I'm staying here for now.
Well, I'm in a real bind now. I uninstalled Thunderbird altogether and reinstalled 1.5.0.8. Pointed it back to my profile and now it locks up when checking my mail. The process is at 34MB. I have four SMTP accounts with no newsgroups and no RSS feeds.

I thought it might have to do with the FIPS encryption, so I removed that to no avail.

Also on the (way off) chance that it was a problem with my AVG e-mail scanning, I disabled that. No dice.

So now I'm stuck with no working Thunderbird at all. I guess I'll have to reinstall with a virgin profile and see if that works. But year end is not when I needed this headache... Argh!

Any suggestions?

did you try updating to 1.5.0.9 to see if that unlocks things?  if it does, then you might try to install 1.5.0.8 over top (as I did) and see if that works (did for me).

best of luck!!
I don't want to stray off topic too much. I definitely experienced this bug, and with no RSS feeds or Newsgroups. So it's real.

But then I stopped using Thunderbird for two days and used a web interface to the mail server. Now I am trying to revert to 1.5.0.8 and upgrade again but I am hosed.

By the way, installing 1.5.0.8 with a virgin profile *is* downloading the mail that's on the server...

I guess I'll upgrade and maybe import the mail? Can it be that my profile is screwed up now. It'd be a huge pain to have to re-enter all the message rules and reconstruct the address book etc. Am I missing an easy solution here?
Restore profile from backup - you do have backups, don't you? If not, you should, drives are cheap and there's free software that can help you with that.
I upgraded to 1.5.0.9. Of course I have a backup :-). No, I really to. I'll try restoring from backup and hope that doesn't reintroduce the problem. I'll report back if there's something that might be helpful towards resolving the core issue. Thanks for the help.
So now I have Thunderbird upgraded to 1.5.0.9. I restored my profile (1.2GB - is that a problem?). When I start Thunderbird with this profile in offline mode the folders all appear to be there in the Folders pane, the messages for the (selected by default) Inbox show up in the message list, and the Welcome to Mozilla Thunderbird! page appears in the preview pane.

One strange thing is that the Stop button is enabled (not greyed out). Why would this be? There appears to be no activity.

Clicking around to different folders and messages seems fine. I can compose a message to be sent later. I can even send it if I agree to "go online". But when I try to check messages, it hangs on the first of 134 messages. My "virgin profile" that I played with half an hour ago downloaded these without a hitch.

The process has grown to 47MB in a few minutes. I think it started around 34MB, but I didn't check this time. CPU usage is at 0%... Nothing.

(In reply to comment #27)
> The memory leak has slowed down a lot without any of my RSS feeds. After about
> 3 hrs, the process is only 28MB and I have not seen the abook error yet.

I am experiencing the bug described in this thread as well but *without any RSS feeds*. I have also noticed that after Thunderbird runs for several hours, the memory usage increases from about 28MB to >120MB.

WinXP Pro SP2 on a P4 3.2GHz with 1 GB RAM
Running AVG Free and ZoneAlarm 

Hope this helps.
It might be interesting to run taskinfo (http://www.iarsn.com/taskinfo.html) and specifically look at the resources TB consumes.  In particular, the amount of memory being used, the number of files open, and the number handles being used. It would be interesting to see if certain operations cause the some resource to get used a lot, and it would be interesting to see what the resource usage is when this bug occurs.

One thing I noticed when doing this is that clicking on a link in TB was consuming about 15 handles every time. This turned out to be because of Eudora's Launch Manager, EuShlExt.dll, in C:\Program Files\Qualcomm\Eudora - renaming that dll fixed the handle consumption problem for me. I don't know if that's a bug in TB or Eudora.

I also noticed that I managed to get two copies of Thunderbird running, because one copy didn't shut down cleanly. Have you seen that? It may have been a one-time thing because the first copy was launched by the installer...
Also, what user privileges are folks running at? Administrative or normal user? I don't know if it matters, but it's a data point.
Same problem here on WinXP SP 2, 32bit single processor machine. No RSS feeds.
Same problem as well.  WinXP SP2. No RSS feeds.  Administrative user.

After I get an hourglass on a folder and restart Thunderbird, I click on that folder and I'm told its rebuilding the summary file.  At this point, if I click on some folders its ok, but others have to their summary file rebuilt.
Not sure if this is related or will help, but I noticed something else today.

I got the message about the history.mab file while writing an email.  After I got the error message, the automatic spell checker was underlining and marking every word as misspelled.  If I ran the spell checker manually, it suggested the word as I had written them.

This may be more an effect of the bug, but thought it may help.  If I close and reopen Thunderbird, everything is fine.
I have been experiencing similar problems: Message saying unable to load address book (even though it loads anyway), message saying unable to load address book history, folders that do not open until I close TB and re-open, and the underlining. I don't know that leaving TB idle is a factor on the last one; it seems to me that it is more a matter of not having opened the folder "recently" (last hour or so?).
I have had the same problems:

Address book doesn't load, folders won't open, and inline spell check flags everything.

The address book and folder problems occur after Tbird has been running for a while. The spell check problem happens from the start.

I first had this problem upon upgrading to .9. It also occurs in 2.0 beta 1, although the  spell check works in the beta.

I am running XP Pro SP2 on a P4 3GHz box with 1.5GB RAM. No RSS feeds. Admin user.



Do you mean Thunderbird 1.5.0.9? 

This is just a wild guess, but can you check if the update service is enabled (tools | options | advanced | update) and see if temporarily disabling it helps? 2.0 has UI for this; not sure if 1.5 does though I would hope it does.
(In reply to comment #50)
> Do you mean Thunderbird 1.5.0.9? 

Correct.

> 
> This is just a wild guess, but can you check if the update service is enabled
> (tools | options | advanced | update) and see if temporarily disabling it
> helps? 2.0 has UI for this; not sure if 1.5 does though I would hope it does.
> 

I will try that, thanks.


(In reply to comment #51)
> (In reply to comment #50)

> > 
> > This is just a wild guess, but can you check if the update service is enabled
> > (tools | options | advanced | update) and see if temporarily disabling it
> > helps? 2.0 has UI for this; not sure if 1.5 does though I would hope it does.
> > 
> 
> I will try that, thanks.
> 

The problem still shows up even if updating is disabled.


Agreed.  I still experienced the folder and hourglass problem with updating disabled.  Have not seen the history.mab message yet.
Is everyone using the default theme? Someone reported in the mozillazine forums that switching from the noia theme back to the default fixed the problem. I've tried running with that theme, however, and haven't had any problems. I also saw a report that running with a proxy server was causing excessive memory consumption, which might be related.
(In reply to comment #54)
> Is everyone using the default theme? Someone reported in the mozillazine forums
> that switching from the noia theme back to the default fixed the problem. I've
> tried running with that theme, however, and haven't had any problems. I also
> saw a report that running with a proxy server was causing excessive memory
> consumption, which might be related.
> 
Yes, I'm using the default theme and do not have a proxy server.

Same here. Standard theme. No proxy. Pretty much plain vanilla.
Ditto.  No proxy, standard theme. [no rss, admin user].
(In reply to comment #57)
> Ditto.  No proxy, standard theme. [no rss, admin user].
> 

Same for me.
Default theme, but I'm using a SOCKS server for all outgoing connections.
I can confirm both effects (address book file error and hourglass) more or less independently of each other on Win XP SP2 (but the address book is named as "impab.mab" in my error message, not "history.mab"). I am not using a proxy server, the update service is disabled and I am using the default theme.
(In reply to comment #53)
> Agreed.  I still experienced the folder and hourglass problem with updating
> disabled.  Have not seen the history.mab message yet.
> 

Just received the history.mab message with updating disabled.
I run the same profile on 2 computers.  (I synchronize the whole profile tree between machines on a jump drive.)  Both XP sp2.  Both with ZoneAlarm & 1GB of memory, but they have different AV programs.  I see the issue on both machines.  Unable to consistently reproduce the .mab message but I've seen it.

What I can reproduce consistently is the hourglass.

1 - Start Thunderbird.
2 - Wait until memory leak accumulates to ~200MB of allocation.  This typically takes a few hours on both systems.  I get a leak of 1-10 megs with each checking of my mail (checked @30 minute intervals for 10 mail box accounts, no RSS, no news).  Also some leaks for viewing folders or particular messages. 
3 - Click on folder in local folders.  Now I get the hourglass.  Typically this is the junk folder, but can be others.  This can also be a Sent box that I haven't viewed for a while which produces the hour glass.

Note that if I view an Inbox (any of the 10) after step 3, the hour glass will clear and I can view the messages in that inbox!  If I select the most recent inbox viewed, the hour glass clears almost immediately.  Others may not clear as quickly.  However, once I get an hourglass for a non-inbox folder, it never clears when the folder is selected or reselected (after going to an inbox).

Last note.  If I get a (lasting) hourglass for a folder.  The .MSF file for that folder is either missing or has 0 bytes.
Neil, are the accounts imap or pop3?

How many messages arrive roughly at each 30 minute interval?

We keep the Inbox.msf files open, so if we're running into a situation where we can't open any more files, that shouldn't affect the Inbox.msf files, but other files like Junk and Sent would be affected.
We've heard reports that creating a new profile and copying over the accounts and mailboxes fixes the issue; we've also had reports that deleting all the .msf files for a profile fixes the issue for some users, though not for others, I believe. I'm definitely inclined to believe this this is somehow profile-specific, since I'm not able to reproduce it on any of my machines, and there don't seem to be common denominators like extensions, or anti-virus programs, or desktop indexers like Google Desktop...
All these accounts are POP3.  One is SSL.  The rest are not.

As far as messages I get a few per hour typically.

I have previously deleted all the MSF files.  The issue remains.

Regarding a profile specific issue possibility, I would note that I've been using this profile for several years (though the mail accounts & folders have under gone changes over time).  Could go as far back as Thunderbird 0.7, but I'm not sure.  I will note that I usually uninstall Tbird and reinstall to upgrade, but on this one I used the internal updater to go from 1.5.0.8 to 9 (20061207).  

It's worth noting that I've been watching more carefully the memory leak today.  Originally thought the leaks were typically associated with the 30 minute automatic checking for incoming mail.  Now it looks like most leaks (not related to viewing my mail or manually checking for incoming) occur at 5 minute intervals.  I have nothing in my settings updating at this interval.


One thing that happens every five minutes is we spend a bit of time running through your folders checking to see if any retention settings need to be applied.  This interval is controlled by the hidden pref - "mail.purge.timer_interval", which is a value in minutes. If you don't have any folders set up with message aging, you could try setting this to a very large value using tools | options | advanced (general) and using the config editor. A value like 10000 will give you a few days w/o this check happening (the only thing you need to be careful of is creating a value that overflows the 32bit integer used to calculate the number of milliseconds in the interval - I believe that's roughly 71000)

If setting that hidden pref AND restarting TB makes the memory increase go away, that would be very interesting. If it makes the hourglass issue go away, that would be even more interesting.
What you say makes since given the process messages accompanying the leaks.  Moreover, the change that you recommended has generated interesting results!

I reset the mail.purge.timer_interval to 3607 (about 2 1/2 days).  The 5 minute memory leaks are GONE.  Moreover, it appears that my impression that I had leaks while checking mail is debunked too.  I see no real evidence of memory leaks now in 45 minutes of running.  Previously in this short time period I'd go from ~45 to ~80 MB!  It typically took about 3 hours to get to the 200 MB and the hour glass.

Obviously it will be a while before I confirm whether this really addresses the hour glass issue.  I'll run over the next few days and see what I see, but my expectation is that stopping the leak has stopped the problem.

I still don't see anything special about exceeding 200MB (and 700 handles) which should generate the hour glass, but I don't know exactly what resources are allocated here.  Maybe it will make sense to the coder who wrote the house keeping routines.  Still don't have a recipe to generate the .mab errors, but I've never had them without having an hour glass situation.  I still presume that they come from the same resource limitation.
Neil, thx very much for the feedback, that was most helpful. My theory is that as part of the purge process, we're opening a .msf db file, loading its contents into memory, and then determining that the db is invalid in some way, and returning an error to the calling code, w/o closing the db. Each time we do this, we leak a file handle, and some memory. The code usually closes the invalid db and deletes the db file on disk it so that it'll get regenerated the next time the user clicks on the folder, but it seems like for some folks that's failing. I need to figure what's causing that.

If you're willing, you might be able to help by turning purging back on and generating a log file, by following these instructions:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

replacing "protocol" with MsgPurge. If you can correlate memory leaks with certain folders getting purged, that might help.  I'm not sure we'll get the information we need, but it might help. It might be the case that certain folders aren't showing up in the log, or are always showing up with an empty last purge time.
I'll make some logs over the next couple days and we'll see what's in them.
I can affirm that setting mail.purge.timer_interval=10000 seems to make both symptoms (address book error and hourglass) go away. Also, nearly all of my .msf files have 0 bytes.
Thx, Christoph - are your folders primarily imap or pop3/local?

The other possible cause for this problem is some sort of problem with panacea.dat - that file is a summary of all the summary .msf files, and we cache data in there so that we don't have to open each individual .msf file to find out things like the last time we purged the folder. If panacea.dat is deleted or corrupt, will open the db's to find this information, and we don't close them, which causes memory bloat and file handle consumption. If this is going on, you should see Thunderbird holding a lot of .msf files open.

I don't know why this would have changed for 1.5.0.9, however.
Primarily local. I have one imap account, but there the .msf files seem intact. Some others are intact, too. But nearly all .msf's in my local mail archive folders have 0 bytes. And yes, the problem appeared only after the upgrade to 1.5.0.9. I don't think it's the panacea.dat since after setting mail.purge.timer_interval=10000 everythng is working fine and there are not many .msf files open when I look with process explorer.
My idea was that somehow the purging code had to open the individual db's because it couldn't get the LastPurgeTime from panacea.dat, which would also mean it wouldn't close the db's. By setting the purge timer interval, you're preventing the purging code that iterates over the folders from ever getting executed.

If you were seeing a lot of .msf files opened before, that would be evidence that the purge code *was* opening db's and not closing them.
I started running a log tonight on the MsgPurge as David suggested.  I also reset mail.purge.timer_interval back to 5 minutes.  This test produced a couple of interesting features.

At first, it didn't seem like I was leaking at all, but then the leaks sharted showing up at the reguler level (about 3 MB per 5 minutes).

When I started to examine the logs - comparing these first few purge cycles to later ones - I noticed that the number of folders processed was increasing! The size of the memory leak appears to be proportional to the number of folders referenced during the purge.  Initially a few folders (the basic five for a single account) were referenced.  Eventualy, nearly every folder is referenced (as we added accouts).  Some folders were indicated by a simple reference like:

0[274760]: mailbox://chaplain%40femtoscan.com@pop.femtoscan.com/Inbox curFolderLastPurgeTime=Fri Jan 19 21:39:45 2007 (if blank, then never)
 
Others showing a purge with the reference like:

0[274760]: mailbox://chaplain%40femtoscan.com@pop.femtoscan.com/Sent curFolderLastPurgeTime=(null) (if blank, then never)
0[274760]: purging mailbox://chaplain%40femtoscan.com@pop.femtoscan.com/Sent

curFolderLastPurgeTime time varies.  Some null.  Some with previous purges.

Along with this progression from a few folders to all.  It progresses through my account groups.  Initially, only the 0th group has folder referenced as above.  Then groups 0 and 1.  Then 0 through 3 twice in a row.  Then 0 and 1 only again.  Overall there is an uneven progression further and further down my list of accounts.  Eventually referencing every folder every time.  And once it is referencing every folder every time (I have about 70 folders in 11 account groups - 10 mail boxes and the local folders), the memory leak is at 3Mb / 5 minute purge cycle.

I followed this until the hourglass reoccurred at 203.9MB and 706 handles.  I also got an .mab error message at this time (after the hour glass) when I opened the address book. 

After the hour glass, I followed the system for 2 more purge cycles.  The log record for these cycles looks like the ones before it.  However, it is interesting to note that the memory allocation did not change for these last 2 cycles!  Apparently once the hourglass occurs, the capacity for leaking resources by this mechanism is exhausted.  

If these logs would help, I'd be willing to pass them on, but the log file is nearly 1MB, so it won't be pasted in here!

Sure sounds like DBs opening and not closing!  I presume the end of resources for new handles is the start of the hourglass.  Interesting that the purge cycle still seems to work, but I guess that is consistent with the .mab errors where the address book responds anyway.
Neil, yes, please, send me the log, with any helpful annotations about resource usage changes that you can add.

The fact that the resource usage stops increasing means that my first theory of re-opening the same db multiple times is wrong, thank goodness. It sounds like we're opening the db as a side effect of asking the folder for information, and since the folder caches its db, the db is staying open. Normally, this information comes from the folder cache, which has panacea.dat as its backing store, and we don't open the db at all. It might be interesting to also attach your panacea.dat file (at the root of your TB profile dir) along with the log.

I do have a patch for 2.0 that attempts to close these db's, so if anyone is seeing this with 2.0, I can checkin the patch and see if it helps them. I'm unable to actually reproduce the problem, however, so the fix is speculative.

Thx very much for helping with this problem, Neil!
er, I take it back - I misread your comments. Once the resources stop leaking, that's probably just because we can't open any more files. But if it keeps leaking every time through even though we're checking the same folders we looked at last time, then it's not simply that we're holding the db's open. I suspect it's not all folders that are causing the problem, but a few bad apples.

It would be interesting to know if the memory usage keeps going up even though the files Thunderbird has open stops going up.
also, it's not surprising that the number of folders processed keeps going up - we loop for a fixed time looking for folders to purge. If we open a db to purge it, that takes up most of the time in the loop (normally we just ask the folder cache, which is very fast). Eventually, none of the folders will need purging, so we'll be looping through all the folders and not find any needing purging. Why that's leaking memory and file resources, I don't know.
David - an addition to my log Email.

While writing and log checking, I had changed mail.purge.timer_interval to 1 minute in order to compress the time it takes to get an hour glass and to get purge events more frequently.  It did. It also changed the ratio of handles to memory at the time the hour glass occurs.  In this case I got the hour glass with 735 handles and only 178MB of memory.  MOREOVER, after the hour glass Process Monitor reports equal numbers (no excess) of IRP_MJ_CLOSE and IRP_MJ_CLEANUP events!  Seems to confirm the handle hypothesis I discussed in the Email.
I had tried deleting all the .msf files and, after several days of use, have not seen the problems I was having reoccur. I have not had any trouble so far with the hour glass appearing or with the address book or spell check being inaccessible.

Memory usage by Tbird hasn't run away either.

Knock on wood. :-)
Does the same purge algorithm apply to the RSS feeds/folders? I have lots of those (some broken) and if I remove the RSS feeds the memory leak slows down considerably.
I believe I finally have a handle on this, if you'll pardon the pun. I was finally able to reproduce the handle leak with Neil's help, and Windows Process Monitor, procmon.exe, a really neat little tool. There's a file summary window that tells you for all files that have been opened and closed, how many times they've been opened and closed.

The reproducible case I have is when the Drafts.msf file is out of sync w.r.t. the Drafts folder. Eventually, we notice this and create a 0 byte Drafts.msf file. Every time after that when we try to open Drafts.msf w/o reparsing the folder, we leak a few handles. I think we're not closing the actual underlying file handle in the 0 byte case, and perhaps other error conditions. I need to step through the db code to be sure...

Why this is happening more in 1.5.0.9, I don't know. It might be that the code to detect folders with invalid message threading causes enough DB's to get marked invalid that we leak more handles than we used to, for some users...i.e, we've exposed the underlying problem.
The Thunderbird DB code does close the 0 byte .msf file after opening it - I believe the mismatched counts has to do with the reporting tools counting opens that fail (e.g., because the file doesn't exist) as opens, but there aren't corresponding closes for those). So I'm not sure anymore that I have a reproducible case, though I do see the handle count go up gradually. I can probably get rid of the failed opens by checking if the file exists before trying to open it.
I concur - in part - about the missing MSFs and opens.  I don't understand which MSFs are deleted and which are left at 0 bytes.  Shouldn't it be one or the other?

I will note that even omitting the opens that fail, I show a handle leak.  I'm still interested in the discrepancy between the device driver clean up and close messages.  (This seems to determine the handle leak rate.)  I don't understand why they don't match in this case - presuming Tbird is the only app opening these files.
The same .msf file is deleted and then created with 0 bytes, over and over again. The process is something like this - we try to open the .msf file, and notice it's invalid - we delete it, and then create a new, empty one. If the user clicked on the folder with the invalid db, we'd reparse the folder, and regenerate the db. But since the db is getting opened for other reasons (e.g., the purge code), we don't regenerate the db, and end up in this cycle.

I don't understand the cleanup vs. close discrepancy either. I've seen it for other files, like impab.mab, which are just opened, read, and closed, without getting written to at all.
I've landed a change on the 2.0 branch this morning that should prevent the cycle of creating a 0 byte .msf file and deleting it every time the purge cycle tries to open a folder with an invalid db. This merely reduces the number of db's the purging cycle will possibly try to open - it doesn't fix any underlying handle leak.  I'm really interested if this fixes the problem for anyone running 2.0 nightly builds - tomorrow's build will have the change. If procmon.exe is to be believed, opening and closing db's sometimes fails to close the underlying handle, but I don't see any rhyme or reason as to why. We're just using fopen and fclose which should be ok...

I might be able to spin up a 1.5.0.x windows release build with the same change if anyone is interested in trying it, but trying 2.0 is easier.
I tried running procmon.exe against TB 1.5.0.7, and saw the same kind of mismatch of opens and closes, with cleanup sometimes getting called w/o close. So either the underlying problem has always existed, but something in 1.5.0.9 has made us open more db's thus making the problem worse, or the tools are lying to us, or the problems are unrelated.
I looked briefly at the 1.5.0.9 code base and saw no evidence that the problem originated in this version.  I expect David's theory that this has existed for a while, and has been exacerbated by other changes in the current version.

I've not been looking at 2.0 builds at all.  Since I'm pretty sure that the leak rate is related to the number of folders & services, I'd want to transfer my whole profile to 2.0 to test it.  Are there any changes in the data structure in 2.0 that could affect temporarily reverting a profile to 1.5?

I wonder if changing the handling of invalid MSFs might help.  Have you looked at specifically truncating invalid files rather than deleting and recreating them?
The only caveat about using 2.0 and 1.5 against the same profile is that if you have any filters or views or saved searches that use labels as a search criteria, they will be upgraded to use tags as a search criteria, so they will break going back to 1.5. But if you don't have any of those, then you can run 1.5 and 2.0 against the same profile w/o problems. I do it all the time.

The recreating of invalid .msf files after deleting them is a bug, basically. I've checked in a patch to 2.0 to fix that. It was actually done by some other piece of code for reasons way too complicated to go into :-)

One thing I noticed about the procmon logs is that in the failure case, where we have a CLEANUP w/o a CLOSE, is that there are no other file events in between the last file i/o operation and CLEANUP, whereas in the success case, there are other file ops on other files in between the last file i/o operation and the CLEANUP/CLOSE. I noticed this specifically in the case where opening the address book files for autocomplete was causing missing CLOSE's - I don't remember if this was true for the .msf case.
After talking to someone here, I thought of a few possible causes for this problem.

The lack of close could be accounted for things like:

multiple calls to fopen on the same file, but only one call to fclose (this leaves a handle with a non-zero ref-count). I don't see how this could be happening in the abook or db code, however, since subsequent calls to open on an already open db just return the db object, and don't re-open the file...

Some other task could be opening files, increasing the ref-count on the handle, but not closing the file (e.g., a desktop search indexer or virus checker, though I know people are seeing this problem w/o those)

Or there could be some bug in the underlying code when we open and close files really quickly - this seems even more unlikely, however.
I installed the 2.0 beta build designated "2007-01-25-04-mozilla1.8"  I see many good things!  I'll keep testing over the next couple of days, but this is my initial feedback.

At this point I've seen no evidence of handle or memory leaks!  Moreover, the change to the Windows CreateFile and CloseFile (instead of fopen and fclose) has removed most of the ambiguity surrounding the IRP_MJ_CLOSE and IRP_MJ_CLEANUP events in the process monitor program.  When I look at the log of the purge mail event sequence everything is clear and understandable with the exception of a handfull of "extra" IRP_MJ_CLOSE calls which seem to affect directory operations.  Even with this excess, very thing seems to get cleaned up and closed as necessary.

I'll want to run this build longer to say more clearly about whether the hour glass and .mab message are gone; however, all of the accompanying featured I used to predict their occurrence are gone.  
Thx for the feedback Neil! That's great. But I don't understand the change to Windows CreateFile and CloseFile you're referring to. Is that a change in the code in 2.0 somewhere?

I might have to spin up a 1.5.0.9 build with the patch I landed in bug 316929 to see if that's what is making 2.0 better.
I downloaded a 1.5.0.10 prebuild "2007-01-25-07-mozilla1.8.0" to test.  It seems to behave similarly to the 2.0b2 build that I mentioned before!

When I spoke about the CreateFile and CloseFile items I was referring to Windows file events logged by procmon.exe.  That is to say, 2.0 and 1.5.0.10 appear to be using different calls to open and close files.  I presumed that these were the result of a change to direct Win32 API calls to these functions (or similar like CreateFileEx) instead of fopen and fclose.  

This was a presumption on my part.  I have not looked at the code base or the compiler settings/includes that might produce such a difference.  (And I wonder about the later case as many compilers with substitute via header macros one of these types of calls for the other.)

As for differences between 1.5.0.10 and 2.0, the 1.5.0.10 build has a large excess of IRP_MJ_CLOSE calls (compared to CloseFile calls.  I presume this is the reult of some type of zeolous clean up of handles (which may be closed already).  1.5 also seems to produce an explicit match between CreateFile calls and CloseFile calls.

David, if this is the result of your changes, I think we are clearly going in the right direction.  I am however, a bit curious about the 2.0 build I tested, because it still produces an excess of CreateFile calls viz-a-viz CloseFile calls (though it doesn't seem to leak).  I'm wondering if the leak plug on 2.0 is only due to the change in OS house cleaning invoked by the change in call type.  If that is the case, the leak might return under other circumstances.  

I really like matching numbers of CreateFile and CloseFile calls I see in 1.5.0.10.  It seems to indicate a much tighter tracking of open handles, and hopefully a more stable code base for future use.


If 1.5.0.10 is working better, that has nothing to do with anything I've done, since I've only landed changes for 2.0. I don't know what's gone into 1.5.0.10 since 1.5.0.9 - it would be interesting to see if you still run into the hourglass problem with 1.5.0.10.
Of course, if invalid .msf files were involved, and the 2.0 did manage to make a a valid one - then 1.5.0.10 wouldn't see the problem either. Do you still see it with 1.5.0.9 now?
2.0 would just remove the invalid .msf file and not recreate an empty, invalid one. But I think 1.5.0.10 would create an empty, invalid one and the cycle would continue. Not sure, though. Running 1.5.0.9 would be a good test.
I'm afraid I've introduced a red herring into this discussion.

After running 2.0 and 1.5.0.10 versions, I reinstalled 1.5.0.9.  While running all three versions, I was using the procmon.exe tool.  It was the tool that showed the change in the IRP_MJ_CREATE, etc. messages.

Well, at this time 1.5.0.9 is behaving pretty much like 1.5.0.10 was yesterday.  ARRRRGH.  That includes showing no sign of the hour glass, .mab message or memory/handle leaks.

I can't say whether the other Tbird installations caused this change, whether it was caused by an update to a presumably unrelated database application on my computer yesterday morning, or even to another patch earlier this week.

Only thing I can figure is to try this at home tonight, as it previously showed the same symptoms, but it has not had any of the above changes. 

I guess this is just another time where "I think, therefore, I am confused."
I removed one confusing item.  I had inadvertently toggled the "enable advanced output" setting in procmon.exe that changed the messages during the purge events.  So disregard the babble about the file event changes.

Nevertheless, I've run all morning without a significant leak (or other adverse events) in 1.5.0.9.  So something in what I've done recently has changed the way the program is cleaning up after itself.

Looks like I'll be retracing my steps for a while.
Thx, Neil. Perhaps it was running 2.0 beta...we'll have to see what happens at home.
"Perhaps it was 2.0 beta"  This now sounds to me like a really good guess! 

I when home with the profile I used when I tested the 2.0b2 and 1.5.0.10pre versions, but before I copied the profile I preserved a 2 day old copy of the profile from the home machine.

When I ran the profile that ran with 2.0 at home.  It still did not leak, did not hourglass, didn't .mab.  However, the file open/close pattern still looked like it did (when it used to leak) rather than how it had been looking at work (but maybe that isn't the real issue).

Didn't make sense, but that was why I saved the 2 day old profile before I over wrote it!!!  I restored the 2 day old version (untainted by the beta).  Guess what!  It leaked and eventually generated the hour glass just as before!!!!!  

So it seems that the profile itself (one or more of the .dat files - panacea is slightly longer in the 2.0 tainted version) is the cause of the leak.  The question is where to look now?  

The main clue seems to be that running the profile with the 2.0b2 build changed whatever was causing the issue.  But also seems to have some effect on the way the msf and directory files are handled - yielding differences in the pattern of calls opening and closing the files during the purge cycle.

If I compare the .dat files in the two profiles, does anyone have an idea of what I'm looking for?
I have been reading this issue with much interest as I have also been experiencing exactly this problem since I upgraded to 1.5.0.9.  It didn't happen before this.  If it would be any help I have Before and After Process Explorer snapshots that I took as soon as Thunderbird was started up and after I got the "dreaded" Address Book message.  I can post these to the issue if anyone thinks it might help the diagnosis.  I find that simply stopping and restarting Thunderbird clears the problem so it isn't a fatal issue, hence I haven't bothered regressing to the previous release.
Re files to compare, panacea.dat and the .msf files are the two most likely files. Does it seem like the purge process is opening less .msf files per cycle than it was before the profile was healed? Normally, the purge process only has to open .msf files to actually apply the retention settings - it doesn't have to open .msf files to see if they're due for a purge because the time of the last purge is stored in panacea.dat. And we only purge folders 8hrs+ after their last purge. Perhaps running the nightly 2.0 build has caused the folder data record containing the purge time stamp to get into pancea.dat, and to stay there, so that we don't have to open the db to see if it needs purging.

It would be interesting to see if the healed profile has 0 byte .msf files after running 1.5.0.9 for a while.
I'm not familiar with the structure of the information in the panacea.dat file.  What I can tell you is that the File list from Process Explorer shows that the same files are appearing over and over again.  They are two .msf files related to first level folders and a .sbd folder associated with second level sub-folders.  This is NOT the only folder with sub-folders.

The .msf files within the .sbd folder are three of six sub-folders.  None of the .msf files have a zero size.  No other .sbd or .msf files appear in the Process Explorer list.

Initially not all of the sub-folders had a related .msf file but these do appear later.  Nevertheless, only the initial three sub-folder .msf files are referred, even after the other .msf files are created.

I can spot nothing special about these folders and sub-folders.
I took some time this evening comparing panacea.dat between the leaking profile and the one that doesn't leak (memory and handles).  (See comment #99.) David deserves the prize; "Perhaps running the nightly 2.0 build has caused the folder data record containing the purge time stamp to get into panacea.dat, and to stay there, so that we don't have to open the db to see if it needs purging." 

This sure looks right since panacea.dat from the leaking version has no, none, zip, nada "LastPurgeTime" entries, while panacea.dat from the "healed" version has LastPurgeTime entries for most (but not necessarily all) of the MSF files.  (The missing stamps that I've checked carefully are all for directories, not folders, but I've not checked everything.)

If I follow the data format correctly (and I'm not sure I do), it appears that the time stamps associated these purge events are cross linked in an undesirable way.  That is to say a number of keyed records (each associated with a particular MSF file or a directory for an individual mail box) all reference a time entered for one particular MSF file purge event.  Put another way, each mail folder and server in the profile seems to have two matched (keyed) data entries, and a number of the purge time entries seems to reference a single time entry associated with one folder - and this strikes me as strange if not unstable.

"It would be interesting to see if the healed profile has 0 byte .msf files after running 1.5.0.9 for a while."  The answer to this questions is - yes it does.  I seem them already.  In on-going operation of the programs - as I write this - I have 23 MSF files that have been deleted from the profile.  (If I'm correct what these have in common is that there are no unread messages in these folders.)  When I exit Tbird, these folders will have MSF files written to the profile.  (They may or may not be 0 byte files and I haven't sorted out the rationale of which file disappear and how are the written at Tbird close.)  When I restart Tbird, some of these files may persist for a while, but eventually they will all be deleted again until I close the program.  This happens independent of profile (healed or not).

Personally I wonder if the healed profile is slowly corrupted, and whether in a few days it will start to act like the old one?  Or is the broken profile an upgrade anomaly that 2.0b2 fixed, due to a failure to properly add the LastPurgeTime during one of the many version updates my profile has undergone since version 0.7?  

Having seen all of this I could resist the question, what happens if one deletes the panacea.dat file?  I presumed that Tbird builds a new one, and yea and verily, I say it tis true.  It also builds one with some LastPurgeTime entries for folders with unread messages. I'm now watching this to see if deleting this file a way to either fix or break the Tbird with respect to the hour glass and memory leak.  (I deleted it from the previously healed version - after saving the healed one of course.)

I'll keep you posted.

It became clear quickly that deleting panacea.dat does indeed fix the problem.  It fixed the problem for the leaking version without creating one for the already healed one, but I don't know how long it will last.  

I do know that the healed version had more changes viz-a-viz the older unhealed copy since the older one shows more mismatches between the file open and close events.  I certainly seems like it shows more signs that eventually accompany the leak though they haven't started.

Obviously none of this addresses the underlying code issues that cause the leak during the purge, but it does limit the number of purges.
All of this is very interesting, but... :-)

Since I deleted all of my .msf files, I have not had any problems with Tbird. the addressbook and spell check problems went away, as did the problem with getting an hourglass upon opening a folder.

It's been a week since I had any trouble.

I am now running 2.0 beta 2 and it's been running all weekend. It's at about 70 MB of memory, but it's still stable so I don't care. :-) (My inbox has 3500 or so messages in it, so I rather expect Tbird to grab some RAM.)



I'm not surprised that deleting all the .msf files helps - running the 2.0 nightly build would have the same effect. Neil, could you send me your "bad" panacea.dat? And maybe your good one too, so I can see what you mean about the cross-linking - the mork data format can be a bit hard to follow, but basically it's a bunch of string dictionaries, and then tables that refer to those dictionaries.
I've been following this discussion with great interest as well; I wish it were easier to find..

I've tried deleting all my .msf files but the problem comes back.

For what it's worth, I haven't seen any mention of another symptom of this problem I've been encountering.  Namely, the folder summaries aren't being maintained the same as they were in 1.5.0.8.

In 1.5.0.8, as I downloaded POP messages, I could see most of the folder message counts update in real time as messages were filtered into them.  Sometimes the .msf would get out of synch or otherwise be considered unreliable, and when that happened the count wouldn't increment.  When I opened folders, either the contents came up immediately, or I'd get the 'building summary file' message.  The former was more common by a factor of about fifty.

In 1.5.0.9, this has turned round.  Any folder that gets messages filtered into it automatically becomes out of date -- unless it's the folder currently open, or the Inbox.  Which means that after a download, the only folders that don't bneed to be rebuilt are the ones that haven't changed.  All others that have been touched by the download now get the 'building summary file' event, and after a while the hourglass situation occurs.

This is all observation, not exact analysis.  I.e., I haven't rigourously verified these points, such as to make sure that *only* the open folder remains in synch.  But I hope this additional info helps some..
I upgraded to TB2 beta 2 using the same profile as for 1.5.0.8/9 and it seems that the high memory consumption and the address book errors are gone. Just like others have noticed.
I've landed the same change that I landed on the 2.0 branch on the 1.8.0 branch, so 1.5.0.10 will have that change - anyone still using 1.5.0.9 might want to try tomorrow's nightly 1.8.0 branch build (which corresponds to 1.5.0.10 - sorry for our complicated version story!)
Any time frame for officially releasing 1.5.0.10? On some systems I would rather not use the TB2 beta ...
1 to 2 weeks, I think, though I'm not sure...
I installed 1.5.0.10 (upgrading from 1.5.0.8) but the bug it's still here. I reverted to 1.5.0.8 again. My system is the same as when I initially opened the bug.
I got this with Thunderbird 2.0 beta 2.

I also found that the Thunderbird search facility would re-build many indexes each time I used it (but not if I used it again in the same Thunderbird session).

As there where several other quirks associated with this .msf file problem, I used, as a prophylactic measure, to run a Thunderbird search over the whole of Local Folders every time I opened Thunderbird.

The re-building has stopped since I disabled the indexing of email by Google Desktop. The messages about .mab files have also mostly stopped since the I disabled the indexing of email by Google Desktop.

I have not tried re-enabling email search in Google Desktop since installing Thunderbird 2.0.0.0 RC1 - but would do if asked to try it.

I should also mention that I'm running Thunderbird on Windows 2000 and my Thunderbird profile is on a Linux file-server. 
I installed version 2.0.0.0 (20070326) and used it for about one week.
The bug is still here, even if its severity is a little reduced.
I keep getting the history and address book errors but with a reduced frequency and in about half of the cases TB keeps working. In the other half of the cases I get the hourglass and any folder I click on displays as empty. Upon a restart TB rebuilds the indices of those folders and I get my messages back.
I'll probably revert to TB 1.5.0.8 again, after all that version works 100% for me.
I also experienced this error in both 1.5.0.9 as well as TB 2, beta1, RC1, and 2.0.0.0. It has been accompanied by the following as well: "unable to open the summary file for ____.  Perhaps there was an error on disk or the full path is too long". I don't know if the latter is part of this problem, or if I should file another bug report for it. Like others, 1.5.0.8 works fine for me, with none of these problems.

Win XP Pro
TB 2.0.0.0
1 GB RAM
2.4 GHz
I no longer have this problem, but I'm not sure when it occurred, so I realize that may not be much help.  I did at some point upgrade to 1.5.0.10 so that could be the reason.
(In reply to comment #114)
> I installed version 2.0.0.0 (20070326) and used it for about one week.
> The bug is still here, even if its severity is a little reduced.
> I keep getting the history and address book errors but with a reduced frequency
> and in about half of the cases TB keeps working. In the other half of the cases
> I get the hourglass and any folder I click on displays as empty. Upon a restart
> TB rebuilds the indices of those folders and I get my messages back.
> I'll probably revert to TB 1.5.0.8 again, after all that version works 100% for
> me.

Paolo, 2.0.0.6 any better?  We still don't know why 1.5.0.8 works for you and 0.9 doesn't?
Wayne, I installed 2.0.0.6 after reading your message and used it for a few hours. I eventually got again the read-only/locked file error message while typing in an address. TB freezed on any folder I clicked on, but not on the one I already had open and on Inbox.

By the way, for the first time I had problems reinstalling 1.5.0.8 over the newest version. Maybe the distance with the last 2.x release is becoming too large. A reboot fixed it.

I think I can stay with 1.5.0.8 pretty much forever because it does everything I need, but if a future release will come with filters on outgoing messages I promise I'll do anything to make it run on my pc .-)
No longer blocks: 364761
Assignee: mscott → nobody
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9)
> Gecko/20061206 Firefox/1.5.0.9
> Build Identifier: Thunderbird version 1.5.0.9 (20061207)
> 
> (this is a summary of a couple of messages at
> http://forums.mozillazine.org/viewtopic.php?t=502234)
> 
> I get the following message at some point in the session:
> 
> "Unable to load address book file history.mab. It may be read-only, or locked
> by another application. Please try again later."

This problem doesn't exist on 1.5.0.7** (and 1.5.0.8), so why is there no discussion of this bug being a regression?  Has anyone examined the bugs that got fixed there?  Is bug 299346 one of them?  (the bug which added the message ""Unable to load address book file ...")

** http://forums.mozillazine.org/viewtopic.php?f=31&t=502234&st=0&sk=t&sd=a&start=15

xref bug 366457  Address Book Corruption / deletion - Possible memory dump appended to original abook.mab file
(In reply to comment #109)
> I've landed the same change that I landed on the 2.0 branch on the 1.8.0
> branch, so 1.5.0.10 will have that change - anyone still using 1.5.0.9 might
> want to try tomorrow's nightly 1.8.0 branch build (which corresponds to
> 1.5.0.10 - sorry for our complicated version story!)


Paolo in comment #118:
> Wayne, I installed 2.0.0.6 after reading your message and used it for a few
> hours. I eventually *got again the read-only/locked file error message* while
> typing in an address. TB freezed on any folder I clicked on, but not on the one
> I already had open and on Inbox.

Paolo, 
Can you reproduce this with the recent beta release?
 http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

backup your profile first
Keywords: regression
Wayne, sorry for this late reply. I recently switched from Windows to Linux so I can't check the beta release. All I can say is that Thunderbird 2.0.0.19 for Linux works well on the very same machine I filed the bug for.
Paolo PMed he's still running clean, and my reading is this issue stopped appearing in the v2 time frame, so closing WFM

I was tempted to add "memory" to the bug summary as a primary symptom, but my impression is not all reporters experienced high memory usage. If that is incorrect please update the bug.
URL: http://forums.mozillazine.org/viewtop...
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Summary: Hourglass on folders window after msg "Unable to load [...] history.mab [...]" → Hourglass on folders window after msg "Unable to load [...] history.mab [...]" after update to TB 1.5.0.9
You need to log in before you can comment on or make changes to this bug.