When Thunderbird itself or computer with open Thunderbird crashes, sometimes it downloads all my IMAP mail boxes from scratch. About 1.5Gb each time... And even during the download it crashes (downloading particular inbox I believe) and begins next time from beginning. Happened a lot of times. Also it "forgets" each subfolder setting "check for new massages". Crash logs: TB5342865H TB5342295H
Happened with 1.0 and trunk builds. new one: TB5343627Q
there's nothing interesting in those talkback reports, at least as far as the stack trace is concerned.
what version of thunderbird are you using? 1.0 or a trunk build?
Currently a trunk 20050419. But when this hapened some time ago, I reverted to 1.0.1 and the same crash happened. Maybe there some particular mail in my box that causes the crash? It hapends about the 80% loading one of my inboxes. After some time all loads fine and works till next crash (corrupting local files?).
are you using Google Desktop Search?
I have seen this as well; Thunderbird 188.8.131.52, but it's happened to me several times with earlier versions on both Windows and (my current platform) Linux. I have noticed it most often happens when I take my work laptop home and VPN back to the office (it's a PPTP VPN if that makes any difference): wild speculation, but I wonder whether it might be to do with either sessions back to the IMAP server timing out or the total length of time required to download new headers.
Andrew, How reproducible is this problem? Is it easy to reproduce? David notes the trace had nothing interesting. Can you try a trunk build http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ and then get the URL for the breakpad report using this query http://crash-stats.mozilla.com/?do_query=1&product=Thunderbird&query_search=signature&query_type=contains&query=&date=&range_value=2&range_unit=hours
Clarification -- after re-reading all the above -- I don't see crashes, I see " sometimes it downloads all my IMAP mail boxes from scratch." In the year since #6 my machine has changed and I don't use the VPN, but I still see this "lose all IMAP mail and rebuild mailbox from scratch" behaviour. It happens when I leave work and come home; I hit the 'work offline' lightbulb icon, get sync'd, and try to make the machine hibernate. This sometimes fails (it's a known h/w issue) leading to a reboot. When Thunderbird next starts - in "online mode" of course - if I'm at home (and the IMAP server's not available) it will then lose all trace of an account's folders and mail. When the server's next available (back in the office), the app chugs away reloading the ~10K messages. I would certainly have searched for other bugs before jumping on this one, but it occurs to me actually a different issue than the *crashes* reported by the original bug reporter?
(lame postscript to my previous comment, sorry) -- or I could try the lost mailbox issue with a trunk build?
yes, this is different than Eugene's report (who we haven't heard from recently) so you should file a new bug - preferably with a *numbered* list of steps to reproduce rather than a paragraph (harder to parse). You don't say if comment 8 is based on Thunderbird v2. As for trunk version (thunderbird alpha) you might give it try - it has fixes regarding hibernate + networking. If you do try trunk, compare it to version 2 and comment.
OK, thanks Wayne, I'll file a new bug with proper steps-to-reproduce. My contribution to the original crash report then is "worksforme". Comment 8 is for Thunderbird 184.108.40.206 - this happened very recently.
Wow... My English is bad. :) So, I mean: I had a very crashy computer that time and it crashed very often. When the computer crashed with open TB, after restarting it TB downloaded all the IMAP folders from scratch. So every time TB reloaded from server all folders, as it would be a new account. Now my computer does not crash and I cannot afford to reproduce it, since I have 6 account about 3 Gb together.
Thanks Eugene. Lacking the top of stack and trace, perhaps it's best to close this out. Please reopen the bug if you see the problem again. => incomplete