User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6 Build Identifier: 3.0b2 since 5feb (last good is Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090204 Shredder/3.0b2pre) All new nightlies are crashing - Mac OSX. Specifically - if I download and run the version at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2009-02-05-02-comm-1.9.1/thunderbird-3.0b2pre.en-US.mac.dmg then it crashes on launch, and Crash Reporter crashes - (we've seen this before on other bugs, where Crash Reporter itself is unstable). I've tested several of the versions since then, up to and including 2009-02-14-02, - they all fail I've also tested several versions preceding that date - they all work - so it looks like something introduced in that version. I'll append the APPLE crash report, the key lines look like .. which is similar to what we saw in previous crashes that also crashed CrashReporter. 0 com.apple.CoreFoundation 0x9316eb82 _CFBundleGetLanguageSearchList + 18 1 com.apple.CoreFoundation 0x9317e96c CFBundleCopyResourceURL + 28 2 com.apple.coreui 0x95e5bec0 CUISharedArtReader::Setup() + 106 3 com.apple.coreui 0x95e5c065 CUISharedArtReader::CreateImageSource(long) + 35 4 com.apple.coreui 0x95e4f533 CreateImageSourceFromDisk(long, CUIContext const*, long*, unsigned char*) + 45 5 com.apple.coreui 0x95e541cd CUIRenderer::CreateImage(long, CUIContext const*, CGRect*, float*, long*, unsigned char*) + 463 6 com.apple.coreui 0x95e33456 CUIRenderer::DrawWindowFrameDark(CUIContext const*) + 782 7 com.apple.coreui 0x95e4819e CUIRenderer::Draw(CGRect, CGContext*, __CFDictionary const*, __CFDictionary const**) + 4638 8 com.apple.AppKit 0x946314f3 _NSDrawThemeBackground + 862 9 com.apple.AppKit 0x946310de -[NSThemeFrame _drawUnifiedToolbar:] + 1086 10 com.apple.AppKit 0x94630593 -[NSThemeFrame _drawTitleBar:] + 860 11 Reproducible: Always

Mitra could you try removing your profile and saving it - because all those version have worked for me. Your profile my be corrupted.

Ludovic - with a new profile (move ~/Library/Thunderbird elsewhere) it works fine. It *is* of course possible the profile is corrupt, BUT it must have been corrupted by existing (earlier) versions of TB, so I don't think it unreasonable to expect TB not to crash when opening it - instead it should be spotting the corruption and fixing it! Also - it should never be the case that CrashReporter crashes, since then there is no way to find out where the problem is.

(In reply to comment #3) > Ludovic - with a new profile (move ~/Library/Thunderbird elsewhere) it works > fine. Ok, that's useful to know. It means that it is less likely to be an issue in core code. > It *is* of course possible the profile is corrupt, BUT it must have been > corrupted by existing (earlier) versions of TB, so I don't think it > unreasonable to expect TB not to crash when opening it - instead it should be > spotting the corruption and fixing it! The only thing I can see that landed between 02-04 and 02-05 nightlies that may have affected this was bug 469448. There's nothing obvious that would cause a crash, and it should, in theory, improve things if you have bad msf files. I'm not sure how many folders you have, but you could try moving msf files out the way to see if one of them solves the problem. The only other option would be to get your profile running with a debug build as that would likely give us a correct stack and/or assertions that point to the failure.

Hi Mark, I have a LOT of folders, including a wider variety of stuff, including for example imports from other mail programs and so on, I think its why I hit so many bugs ! I'm wary of deleting msf files - as I did before - as it loses all my tagging and starring. Happy to run a debug build, if I could figure out where to get it, there is nothing obvious in http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/ which is where I get my .dmg's from. I do *not* have compilation setup here.

I've just emailed Mitra with details of how to get hold of a debug build I've done and how to run it.

As requested by Mark, I installed a debug version from his site, and ran it in the terminal, this is a save of the text from that Terminal session. The debug version appeared to crash in the same function as reported above, except I don't think it invoked Crash Reporter - which probably also needs debugging to find out why it crashed instead of reporting the crash.

Was that debug useful? I'd love to be able to keep testing on nightly versions.

have you tried starting in safe mode, or turning off extensions, like junquilla?

fair point, I disabled the extensions (in a working version of Shredder), exited that program, then run the test again, I've just uploaded the trace, so it doesn't look like either of those extensions are responsible for the problem. I have NOT tried doing anything to indexes etc, other than normal usage, as I'm presuming that its useful to track this down - i.e. even if my profile is slightly corrupt Shredder should NOT be crashing on it.

In response to your other suggestion - I'm not sure what it means to start Shredder in "Safe mode" - I'm happy to try that if it would provide useful information. (Preferably without it rebuilding index and losing all the tags etc)

Starting in safe mode is done by adding -safe-mode on the command line. It effectively disables all extensions/themes. Interesting output at the end of the dump, a few others are having this problem as well: http://forums.mozillazine.org/viewtopic.php?f=29&p=5811765 Mitra, is the apple crash reporter coming up with my build? (i.e. a stack/further details) - as my build has symbols, it may have more info. Also, in the good 2009-02-04 build, could you set your start page to about:buildconfig temporarily (in general preferences) and then select Go -> Mail Start Page. Once you get that page there should be a line like: Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/xxxxxxxxxxx (where xxxxxxxxxxx is a set of numbers/letters). Can you paste that here as it will help with looking for possible candidates for the regression.

Thanks Mark. The good release Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090204 Shredder/3.0b2pre was built from: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1ae4df77ef16

mark - yes Apple's crash reporter comes up, and its attached.

Ok - as requested - trace as started in safe mode, they all look the same if we look at the end of the dump

Comment on attachment 363657 [details] Apple crash report from mark's debug version Thanks for attaching this, unfortunately, I don't trust it, e.g. nsVoidArray::AppendElements doesn't recursively call itself. Marking obsolete as this isn't useful data.

Regression windows: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-02-04&enddate=2009-02-05+03%3A00 http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-02-04&enddate=2009-02-05+03%3A00 The mozilla-1.9.1 is definitely correct window (checked via about:buildconfig). The comm-central regression range is probably about right. I'm currently thinking bug 469448 may be the cause here (due to the mork assertions in Mitra's logs). On this hunch, I'll try doing a build with that bug backed out for Mitra to try.

(In reply to comment #16) > (From update of attachment 363657 [details]) > Thanks for attaching this, unfortunately, I don't trust it, e.g. > nsVoidArray::AppendElements doesn't recursively call itself. Marking obsolete > as this isn't useful data. looking at the offset, I'm guessing that's just the closest symbol it knows about - it's a different function, though, which very well might call itself. nsVoidArray::AppendElements(nsVoidArray&) + 238224 The OS/X function calls look like they're the actual functions getting called, though.

I'm a bit worried about releasing without a fix for this. We're planning on tagging build2 in about 2 hours

I wonder if this is the same crash justdave has been seeing since before b1, where we're crashing in the password prompt code, I think because we have two ssl connections causing password prompts.

(In reply to comment #20) > I wonder if this is the same crash justdave has been seeing since before b1, > where we're crashing in the password prompt code, I think because we have two > ssl connections causing password prompts. bug 463970? AFAIK no significant uptick of crashes since bug 469448 (except the crap on crash-stats from a long fixed core bug in 1.9.1). So in either case, doesn't seem like this is something to worry about

yes, the stack in bug 463970 looks very similar.

Mitra, assuming you have more than one account (accessed via SSL), could you try disabling check for mail on startup? This may help us know what the issue is.

Mark - "Check for mail on startup" was already disabled (on all accounts). Regarding Crash count, note that this crash - and a that in a previous bug - do NOT run TB's crash reporter, so they probably aren't being counted. Whatever causes this crash, also causes crash reporter to crash while reporting it. Which suggests that the bug is in something more basic - like reading the profile as suggested by the trace, i.e. in code shared by both TB and Crash Reporter. Mark - did you do that build you want me to test. (with 469448 backed out)

One other suggestion - I don't know the code, so maybe not useful. I'm wondering if a debug build of Crash Reporter would be useful for me to test, presumably that is doing something much simpler and still crashing. This wasn't in the debug build Mark sent me last time?

(In reply to comment #24) > ... > > Whatever causes this crash, also causes crash reporter to crash while reporting it. there is just one open breakpad crash - bug 461702. Perhaps Ted can advise.

Bug 474717 was another where Crash Reporter crashed. Note that this wouldn't be still open as the bug it was reporting was fixed. Mark - the version you sent me just now, with Bug 469448 backed out, ran fine, so it looks like that bug is the problem. I'm not sure how this relationship should be added here on Bugzilla.

(In reply to comment #24) > Whatever causes this crash, also causes crash reporter to crash while reporting > it. Which suggests that the bug is in something more basic - like reading the > profile as suggested by the trace, i.e. in code shared by both TB and Crash > Reporter. There is essentially no shared code between Thunderbird and the Crash Reporter, FWIW. The Crash Reporter uses all native system libraries to perform its work, and doesn't touch the application profile, except for the actual crash report file itself.

(In reply to comment #27) > Mark - the version you sent me just now, with Bug 469448 backed out, ran fine, > so it looks like that bug is the problem. Thanks, just to double-check, can you try either yesterday's or today's nightly as well please? > I'm not sure how this relationship should be added here on Bugzilla. I've added it on the list.

The current one (24 Feb 4:27am) crashes - I can't get the version string since it crashes

Mitra, there's been one startup crash fix checked in over the weekend (bug 480556), whilst I doubt it will solve your issue, could you give the latest nightly a try please?

Hi Mark, I have the same issue as Mitra: crash at startup with TB 3.0B2 while 3.0B1 and 2.0.x releases are ok. Crash occurence: 100%. As you suggested, I tried the latest nightly builds and it still crashing. For reference I tried 2 nightly and both are crashing: thunderbird-3.0b3pre.en-US.mac.dmg 02-Mar-2009 04:25 18M thunderbird-3.1a1pre.en-US.mac.dmg 02-Mar-2009 07:01 18M Let us know if we can activate some traces, logs, anything that might help. Nicolas

Nicolas, do you have an imap account that's loaded at startup? If so, there's a small chance you might be seeing bug 480870, in which an imap protocol log might be helpful.

David, I have one IMAP account and two POP accounts checking at startup. TB 2.0.x : checking at startup works TB 3.0B1 : only IMAP check at startup works, for POP account I need to click on the check button manually I disabled the automatic check of all accounts, and tried TB 3.0B2 : it still crash at startup. I don't believe my crash is related to IMAP. Let me know if imap or pop logs can be helpful, I will see what I can do. Nicolas

moving to b3 - figuring this out should block.

I'm having the same issue. Removing profile.ini allowed 3b2 to start up. I'm POP only, no IMAP and I really would prefer to not have to rebuild all of my email accounts. Running on the command line produced the following: rmiracle$ ./thunderbird-bin rmiracle$ Warning: unrecognized command line flag -foreground Thu Mar 5 09:06:21 thunderbird-bin[646] <Error>: cmsDataProviderGetBytes : CMCloneProfileRef: returned -4204 Thu Mar 5 09:06:21 thunderbird-bin[646] <Error>: CMSValidateProfile : Unable to read ICC profile Thu Mar 5 09:06:21 thunderbird-bin[646] <Error>: cmsDataProviderGetBytes : CMCloneProfileRef: returned -4204 Thu Mar 5 09:06:21 thunderbird-bin[646] <Error>: CMSValidateProfile : Unable to read ICC profile -safe-mode results in the same crash (though I didn't get the warning about no -foreground option). Hope this helps. Rob

Hi Mark My machine was in the shop for a new keyboard, and I got a disk upgrade - with cloned data at the same time. This shouldn't have broken TB, but now even the previously good - 4thFeb version won't run, and when run from the command line generates the error message about not being able to read the ICC profile. Running that debug version you gave me (dated 15feb, though i don't know which version of TB it was based on) shows the same crash, as does the current version from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/thunderbird-3.0b3pre.en-US.mac.dmg Is it worth building some more diagnostics into a debug version, and then sending me that to test - for now I'm back to working on webmail ! Any ideas? - Mitra

This is really strange, and similar to behaviour I've seen before, even restoring ~/Library/Thunderbird from Time-Machine doesn't work. As I've suspected before, I think either Thunderbird is using something in the file system that isn't getting backed up. OR its writing to somewhere else in the filesystem - some temp directory or something. Anyone got any ideas - Mark, if it makes easier we could bounce debug versions back and forth on skype and narrow this down, because as the reports above show its not just me seeing data corruption issues that lose all your email!

I've found a workaround for people facing this crash , it MIGHT give clues as to the problem. Copy all the SUBDIRECTORIES (*.sbd) out of the profile, then start Thunderbird, for me it came up fine, I then quit thunderbird, copied each folder back one at a time, restarting TB each time. Surprisingly even with all of them copied back it restarted OK. I don't think this lost any data - e.g. unread/read/star/tag status in sub-folders. - Mitra

(In reply to comment #40) > Copy all the SUBDIRECTORIES (*.sbd) out of the profile, then start Thunderbird, > for me it came up fine, I then quit thunderbird, copied each folder back one at > a time, restarting TB each time. Surprisingly even with all of them copied back > it restarted OK. This would suggest an issue with either subfolders, or msf files. I'm assuming you've still got the original failing profile? There's two things I can think of trying: 1) Kill the .msf files (maybe all at the same time, or one at a time). I expect this may loose some data depending on your servers, but if it succeeds then it implies one of them got corrupt or we can't handle something that we did before. 2) Start up whilst having a protocol log for imap/pop (http://wiki.mozilla.org/MailNews:Logging), I very much doubt this will show anything though.

This is not the only bug I've seen where people report issues after a restore. Thinking about moving it to MailCore:backend - mark thoughts ?

(In reply to comment #42) > This is not the only bug I've seen where people report issues after a restore. > Thinking about moving it to MailCore:backend - mark thoughts ? I don't think this is just restore, I think this is a problem with general upgrades, though its hard to tell at the moment. This probably should be MailNews Core: Backend, but I'm tempted to wait till we know a bit more.

Thanks Mark, yes I have the broken profile still. If I kill all the .msf files it starts ok (but as noted it loses data). Imap/pop aren't relevant, I don't Get Mail on startup (to avoid this kind of issue). I have a feeling it is something to do with restoring, copying files etc, possibly something to do with dates on files. As I said, I'm happy to try a debug version on the bad profile to help track this down more. - Mitra

(In reply to comment #44) > If I kill all the .msf files it starts ok (but as noted it loses data). ... > As I said, I'm happy to try a debug version on the bad profile to help track > this down more. The only thing I can think of now is to determine if there's one specific msf file causing the problem. I'm not convinced that is the case, but I'm out of ideas at the moment, maybe David has some?

the morkConfig assertions indicate that a mork db has problems, either a .msf file, panacea.dat, or an address book (or we're trying to tell mork to open a file that doesn't exist). Most likely it's a .msf file, though. We shouldn't be opening .msf files on startup, other than the folder that's selected, if any (and you say you've set it up not to load any folders on startup, and you still crash?). We should just be getting things from panacea.dat, for the most part... Since mork corruptions should be exceedingly rare, we could add a diagnostic output when we actually encounter them and see if you're hitting that. Or, I wonder if you could use the activity monitor to see what the last file TB tried to open before it crashed, though crashing outside the debugger probably closes the files TB opened.

Hi David, I don't know what "Loading" a folder means, At startup I get the blank config page, and it doesn't "Get Mail" on startup. Sorry, "use the activity monitor" doesn't mean anything to me. Adding a diagnostic output before crashing sounds like a good idea, I could run it from the command line, one level higher might be to output a list of files accessed, so we can track it down to a specific file. We've still got three problems 1: Why do these files get corrupted - and from other reports on this bug, its not just a one-off that I'm seeing. 2: Why does TB crash rather than report, fix, rebuild MSF or whatever? 3: Why does CrashReporter crash rather than report? These all seem like problems that need fixing to give TB some resilience to failure. Possibly tackling the third problem might also be worthwhile as supposedly CrashReporter shouldn't even be looking at these files? I'm wondering if there is a way to run CrashReporter from the command line with some kind of debug option?

(In reply to comment #46) > Since mork corruptions should be exceedingly rare, we could add a diagnostic > output when we actually encounter them and see if you're hitting that. Or, I > wonder if you could use the activity monitor to see what the last file TB tried > to open before it crashed, though crashing outside the debugger probably closes > the files TB opened. Tools > Activity Manager might catch it with a screen movie/recorder app

You shouldn't have to "catch" things. The activity manager backend and autosync are full of good logging logic. There's probably a wiki page somewhere that needs to be written describing how to set the logging prefs for the various bits, though. If you look at http://mxr.mozilla.org/comm-central/search?string=configuredlogger you'll find a bunch of names (e.g. "moveCopyModule"). To turn on logging for that logger, for example, you can define one of two string prefs: moveCopyModule.logging.dump and moveCopyModule.logging.console with values like "error", "warning", "info", "debug", "all". The first one will direct logging to stderr, the latter to the JS console.

Absolutely some isntructions are needed. Sometimes I think people forget that testers aren't necessarily TB developers. I've developed on other things but I've no idea a) which strings to define b) where to define them ! As a tester, I'm more than willing to follow a set of instructions, to setup to test a specific thing to narrow down the bug, but not to piece together a lot of information in different places to figure out what test to run !

Sorry for the cascading confusion - I was suggesting the OS/X Activity Monitor, which is under Applications | Utilities - it allows you to see which files any given program has open - but if Thunderbird crashes on startup, it may not be so useful. I think what's needed here is a bit more diagnostic logging added to Thunderbird, but I'm a bit swamped at the moment. You could try moving away the .msf files for a single account, see if you can startup, if not, move away the .msf files for a different account, etc, until you figure out which account is causing the problems. Then, you could try moving away half the files in the problem account, etc. It's tedious, but perhaps better than waiting for me to get my head above water.

David - What you suggest is a good workaround - I was doing exactly this when I discovered that just moving the sub-folders out, and copying the exact same subfolder back in fixed it - which suggests that something caused TB to reindex the MSF file, or to ignore whatever was causing it to crash. That got me the data back - trouble with real testing is that you need to use real data, and that makes it data you don't want to lose! Of course - that doesn't fix the bugs (Corruption; Crash on Corruption; Crash Reporter crash) so I've kept the bad profile around, and we can fix it when you get the logging installed, or someone tells me how to enable the logging that is already there.

Has there been any progress made with this bug? I've tried to do the move out / move back technique, but I think my problem is happening with one of several multi-tier folder's with dozens of mailboxes in each. It crashes after it checked the plug-in's. Which gave me a chance to get Activity Monitor up and spy on the open files. Here is the last file list before it crashed, don't know how much use it will be: / /Applications/Thunderbird 3b2.app/Contents/MacOS/thunderbird-bin /Applications/Thunderbird 3b2.app/Contents/MacOS/libmozjs.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libxpcom.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libxpcom_core.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libplds4.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libplc4.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libnspr4.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libsmime3.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libssl3.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libnss3.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libnssutil3.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libsoftokn3.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libldap60.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libprldap60.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libldif60.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libsqlite3.dylib /System/Library/Fonts/LucidaGrande.dfont /private/var/folders/vL/vLzJToDJG7m-lh5jBYYEy++++TM/-Caches-/com.apple.ATS/annex_aux /Applications/Thunderbird 3b2.app/Contents/MacOS/components/libalerts_s.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/components/libjsd.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/components/libxpinstall.dylib /System/Library/CoreServices/Encodings/libSimplifiedChineseConverter.dylib /System/Library/Keyboard Layouts/AppleKeyboardLayouts.bundle/Contents/Resources/AppleKeyboardLayouts-L.dat /System/Library/Caches/com.apple.IntlDataCache.le.kbdx /usr/share/icu/icudt36l.dat /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/HIToolbox.rsrc /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/English.lproj/Localized.rsrc /private/var/folders/vL/vLzJToDJG7m-lh5jBYYEy++++TM/-Caches-/com.apple.IntlDataCache.le.sbdl /System/Library/Caches/com.apple.IntlDataCache.le.tecx /System/Library/TextEncodings/Unicode Encodings.bundle/Contents/MacOS/Unicode Encodings /Applications/Thunderbird 3b2.app/Contents/MacOS/libnssdbm3.dylib /Applications/Thunderbird 3b2.app/Contents/MacOS/libfreebl3.dylib /Library/Caches/com.apple.LaunchServices-023502.csstore /Applications/Thunderbird 3b2.app/Contents/MacOS/libnssckbi.dylib /System/Library/CoreServices/Encodings/libTraditionalChineseConverter.dylib /Library/Fonts/Corsiva.ttf /Library/Fonts/CorsivaBold.ttf /Library/Fonts/TrajanPro-Regular.otf /Library/Fonts/NewPeninimMT.ttf /Library/Fonts/NewPeninimMTBold.ttf /Library/Fonts/NewPeninimMTInclined.ttf /Library/Fonts/NewPeninimMTBoldInclined.ttf /Library/Fonts/MesquiteStd.otf /Library/Fonts/RosewoodStd-Regular.otf /Library/Fonts/Silom.ttf /Library/Fonts/InaiMathi.ttf /System/Library/Fonts/HelveticaNeue.dfont /Library/Fonts/OsakaMono.dfont /Library/Fonts/AGaramondPro-Regular.otf /Library/Fonts/Courier New.ttf /System/Library/Fonts/Times.dfont /Library/Fonts/MarkerFelt.dfont /Library/Fonts/DevanagariMT.ttf /Library/Fonts/DevanagariMTBold.ttf /Library/Fonts/Kokonor.ttf /Library/Fonts/Futura.dfont /Library/Fonts/GillSans.dfont /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras2.rsrc /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/Resources/SArtFile.bin /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/Resources/ArtFile.bin /Library/Fonts/#PCmyoungjo.dfont /Library/Fonts/AdobeSongStd-Light.otf /Library/Fonts/\xe5\x8d\x8e\xe6\x96\x87\xe6\xa5\xb7\xe4\xbd\x93.ttf /usr/lib/dyld /private/var/db/dyld/dyld_shared_cache_i386 /System/Library/CoreServices/Encodings/libJapaneseConverter.dylib /System/Library/CoreServices/Encodings/libKoreanConverter.dylib /dev/null /Users/rmiracle/Library/Thunderbird/Profiles/boj58wh4.default/.parentlock /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras2.rsrc /Users/rmiracle/Library/Thunderbird/Profiles/boj58wh4.default/permissions.sqlite /Applications/Thunderbird 3b2.app/Contents/MacOS/chrome/messenger.jar /Applications/Thunderbird 3b2.app/Contents/MacOS/chrome/classic.jar /Applications/Thunderbird 3b2.app/Contents/MacOS/chrome/toolkit.jar /Applications/Thunderbird 3b2.app/Contents/MacOS/chrome/en-US.jar /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/HIToolbox.rsrc /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/English.lproj/Localized.rsrc /Users/rmiracle/Library/Thunderbird/Profiles/boj58wh4.default/cert8.db /Users/rmiracle/Library/Thunderbird/Profiles/boj58wh4.default/key3.db /Users/rmiracle/Library/Thunderbird/Profiles/boj58wh4.default/cookies.sqlite /Users/rmiracle/Library/Thunderbird/Profiles/boj58wh4.default/cookies.sqlite-journal /Users/rmiracle/Library/Thunderbird/Profiles/boj58wh4.default /Users/rmiracle/Library/Caches/Thunderbird/Profiles/boj58wh4.default/Cache/_CACHE_MAP_ /Users/rmiracle/Library/Caches/Thunderbird/Profiles/boj58wh4.default/Cache/_CACHE_001_ /Users/rmiracle/Library/Caches/Thunderbird/Profiles/boj58wh4.default/Cache/_CACHE_002_ /Users/rmiracle/Library/Caches/Thunderbird/Profiles/boj58wh4.default/Cache/_CACHE_003_ /Users/rmiracle/Library/Caches/Thunderbird/Profiles/boj58wh4.default/XUL.mfasl /Applications/Thunderbird 3b2.app/Contents/MacOS/chrome/newsblog.jar /Applications/Thunderbird 3b2.app/Contents/MacOS/chrome/comm.jar

I notice that neither panacea.dat or any .msf files are open - panacea.dat would be open if we had opened any .msf files, I think. Do you have a pancea.dat file at the top of your profile dir? If so, you could try moving it away...

I renamed it to a temporary name, launched 3b2 and it created a new panacea.dat file, zero bytes before it crashed.

While filing some messages today, I noticed I had a set of duplicate folders and it had a random 8 hex digit number appended to the end. They appeared to be empty (and the original had a bunch of messages). With panacea.dat in place and removing the hex code from the end, 3b2 recreated a new set of folders with the hexcode attached before it crashed. I tried removing pananca.dat completely and it still crashed leaving a zero byte panaca.dat. I removed the folders in question and another set of folders with the same behavior, thinking that could be my corrupt content but no luck. 3b2 still crashes. I also tried removing panacea.dat and letting 3b1 create it fresh, that causes 3b1 to crash and also kill the crash reporter. Interestingly enough my mac thinks that panacea.dat is a VLC player file.

the hex numbers imply that you have some folders with non-alphanumeric characters in the name (characters that aren't legal in the file system), so we have to use hex chars in the actual folder names. But we hide this from you by storing the pretty name in the .msf file, and panacea.dat. If the .msf file gets thrown away, then we lose the pretty name. If you throw away panacea.dat, it forces us to open all the .msf files in your profile.

Are you by any chance using google desktop ?

No. Just the standard OS X 10.5.6 desktop. Well it could be something involving panacea.dat since when I delete it, 3b1 crashes as well, so perhaps that process of opening all the .msf files is a problem. Now the .msf holds the read/replied/forwarded statuses right? I'm not using labels anywhere. So I almost don't mind blowing away all of the .msf files and let 3b2 rebuild them, but since this was a pretty wide spread problem, I think having system that crashes is useful to help find the bug. I guess my next step is to try to narrow it down to see if it is an msf file.

I've conducted some brute force debugging on this problem today. Before I started, I had a Staff folder and underneath it I had it organized by department, and each employee having a folder in the department (mbox and .msf file). I'd move stuff out and 3b2 would run fine. I started moving things back in and eventually it would start crashing. I saw three separate crash types: 1. A message about a security issue with a suggestion that the profile was corrupt (didn't write down the specific language), this was the least often crash. 2. Crash reporter would not crash, but it would say that there was no crash report and I'd have to click the acknowledge button a dozen times or so to clear it. 3. The app and crash reporter crashed as above. So I decided to put all employees in a single folder. Using the Mac finder, I lined things up so it was two columns so I could see where I had an mbox and a .msf file per person. For some people, there were no .msf files. I would watch 3b1 create .msf files for about half the people who didn't have them to begin with and the other half just wouldn't get them. I pulled out the mboxs with no .msf files and ran 3b2. It deleted the .msf files that 3b1 just created before it crashed. The other mboxes that originally had .msf files remained unchanged. The next experiment involved only having the ones that had native .msf files. 3b2 starts fine. Next I moved them out and moved the ones in that 3b1 was creating .msf files for, 3b2 started fine (these boxes were all empty btw which was a bit unexpected, however its people I don't get email from often and I recently (Jan 1) archived older posts, so they could legitimately be empty and I now had .msf files for them. I moved them to a holding folder with the known good mboxes. The next test was to load the ones that 3b1 refused to make .msf files for. There are several people in here that I filed emails in earlier today, I know they have content. 3b2 launched fine. So I have no mailboxes that are causing crashes. I move all the known good ones back in *BAM* crash (type 2 above). There are 81 mailboxes. In the process of trying to determine what was going on, I did weed out a bunch of mailboxes of former employees. This sounds and feels like a resource exceeded bug. With over a hundred mailboxes in this one folder, I get the type 3 crash which nukes the crash handler. With 80+ it seems to crash a bit nicer. Hopefully this will help. Rob

Rob, thanks for doing those tests. b2 had a known issue where it would leave the .msf files open for all local folders. That is fixed in nightly builds, so if you could try a 3.0b3pre build, it would be interesting to see what it does: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/

Interesting 3b3pre doesn't crash.

since 3b3pre doesn't crash, I'm taking this off the 3.0 blocking list. Sounds like you were right about it being a resource issue...

(In reply to comment #52) > David - What you suggest is a good workaround - I was doing exactly this when I > discovered that just moving the sub-folders out, and copying the exact same > subfolder back in fixed it - which suggests that something caused TB to reindex > the MSF file, or to ignore whatever was causing it to crash. That got me the > data back - trouble with real testing is that you need to use real data, and > that makes it data you don't want to lose! > > Of course - that doesn't fix the bugs (Corruption; Crash on Corruption; Crash > Reporter crash) so I've kept the bad profile around, and we can fix it when you > get the logging installed, or someone tells me how to enable the logging that > is already there. Mitra, do you still see same problem using latest trunk and your old(saved) profile? ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.1/ and backup your profile first

I still have a saved profile that crashes both TB *AND* the CrashReporter on startup, I don't know if it was the one related to this bug. I really think that there shouldn't be any DATA that crashes CrashReporter - it rather takes away the point of having a CrashReporter at all !

Mitra, I think Wayne referred to testing the build from the link he gave in comment #64, and seeing whether that crashes with your old (saved) profile.

I'm pretty sure thats what I'm auto-updating to ... i.e. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090621 Shredder/3.0b3pre

See Bug 502310 I'm seeing similar behavior, or unable to start Shredder on a corrupt database, it may or may not be the same bug. - Mitra

Has anyone tested Mitra's profile(s) on their machine?

(In reply to comment #69) > Has anyone tested Mitra's profile(s) on their machine? I would need to have the Porfile to do that :-)

Right - and the corrupt profile is 3.5GB and has all my personal emails in it.

I mean just the profile bits minus messages. Or you could create a new, reduced profile and eliminate most of the mail folders.

If I eliminate the messages, the profile works correctly (see Bug 502310), I can send them if you need them, please let me know which parts you need, or which files I should delete before sending to preserve reasonable privacy. - Mitra

the only other identified regression from bug 469448 is bug 481065. Is it possible that the patch in that bug missed something?

If we could get a stack trace of the crash, we'd have a chance of figuring out what's happening.

(In reply to comment #75) > If we could get a stack trace of the crash, we'd have a chance of figuring out > what's happening. So for that Mithra would need some assistance. First we'd need to give him a mac debug build then someone should be online and help him get the stack trace. Mitra being in Australia I think It would be possible for Gary to help here and make Mitra go step by step so we get the stack trace.

(In reply to comment #76) > (In reply to comment #75) > > If we could get a stack trace of the crash, we'd have a chance of figuring out > > what's happening. > > So for that Mithra would need some assistance. First we'd need to give him a > mac debug build then someone should be online and help him get the stack trace. > Mitra being in Australia I think It would be possible for Gary to help here and > make Mitra go step by step so we get the stack trace. Didn't we have a tryserver debug build?

Mitra, did we determine whether anyone else with Mac and the message(s) you identified could recreate?

Nope - no followups to suggestions made, and its old enough now that I don't think I have the corrupt portfolio. Maybe you better close it :-( and hope noone else hits the same problem - Mitra

Since we don't have testcase, let's opt for incomplete.

Rob, Mitra, I'm revisiting this because there is a getsatisfaction topic that cites the "CMSValidateProfile : Unable to read ICC profile" that rob was seeing. http://getsatisfaction.com/mozilla_messaging/topics/helpppppp?topic_tools=open Rob, Mitra, were you not able to get a stacktrace on the profile data that was causing the crash? https://developer-stage.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#Mac xref https://bugzilla.mozilla.org/show_bug.cgi?id=475537 Mac https://bugzilla.mozilla.org/show_bug.cgi?id=507876 Mac

All the tests that were asked were done - and posted above, I've not got any more information on it and no longer have the corrupt profile that caused it (the bug is over a year old). - Mitra

-> WORKSFORME. Fixed is used for bugs with known patches. https://bugzilla.mozilla.org/page.cgi?id=fields.html#resolution

Like Mitra, I provided all I had.

(status reflects Mitra - untested after comment 82, and not fixed after comment 67/68 with bug 481065 fixed)

Yes - hopefully we'll either not see it again, OR next time someone can jump on it and figure out what crashes Crash Reporter !

(In reply to comment #86) > Yes - hopefully we'll either not see it again, OR next time someone can jump > on it and figure out what crashes Crash Reporter ! We do know what often crashes the reporter, and this bug is probably an example. In the case of Thunderbird, file corruption and other mork issues often cause the TB process to be out of memory, and crash reporter fails when there is no memory in which to run :) The situation won't change until either a) TB file system failures don't cause out of memory as often b) dumps and crash reporter run in their own process, per Bug 587729 - Do all minidump generation out of process