I've been having issues trying to get Shredder to run on my new laptop after migrating from an original MacBook Pro to one of the new ones that just came out last month. Other than the obvious hardware change, the only major difference I can think of in the underlying system is that the new one has a case-sensitive filesystem, where the old one was case-insensitive. If I start Shredder with a new profile, it works fine, however with the profile I've been using for years, which has a TON of data in it (my daily backups of it are 1.2 GB compressed) it will never get any windows open, and slowly consume about half a GB of memory over 2 or 3 minutes, then crash. I've been working with various people on IRC without much success trying to track down the issue. It was suggested to file a bug, even though I don't quite know what's actually at fault to pin it on for a detailed bug report. I will attach a console log and a crash dump momentarily.

I did a quick comparison of my working test profile with my broken daily use one, and all of the files and directories they had in common did have the same case in both. My next guess (if we keep following the case-sensitivity lead) is filename references in config files. All of the paths I see listed in prefs.js look like they're binary blobs instead of basic pathnames, so I'm not sure how to interpret those.

Josh, Dave's stack from comment #0 shows a potential Cocoa issue, is this TB-specific? (also, what more info do you think is needed to help Dave debug the problem?)

For the record, I reformatted the MBP as case-insensitive (to match the old one) and restored the backup, and it's still crashy, so that rules out the case-sensitivity thing. On Gary's recommendation on IRC I also tried it with last night's nightly build (instead of my self-built one) and I still get a crash, but Breakpad intercepts it and says the application failed to leave a data file, so I can't get a stack dump out of the nightly.

Dave, have you customized Thunderbird's display in some way? Have you installed one or more Apple "extras" (in your home directory or at the OS level)? The top part of your stack (above -[NSGrayFrame drawRect:]) shows the OS drawing (part of) the top-level NSView in your Thunderbird window (an NSGrayFrame object, which is undocumented, and which includes the titlebar). It also shows the OS drawing some kind of image (and the CreateImageSourceFromDisk() call indicates it's getting that from a local file). All the coreui.apple.com stuff seems to be from Apple. But grepping the /System/Library/Frameworks directory on my (fully updated) OS X 10.5.5 installation for "CUISharedArtReader" returns no hits.

from the stack trace, it looks to me like we're crashing trying to display an nss dialog about an invalid/mismatched domain cert.

(In reply to comment #7) The nss dialog is in a separate window, no? But (from the fact that it occurs while drawing an NSGrayFrame object) I suspect the crash happens while the OS is trying to draw part of that window's OS-level "chrome" (e.g. things in the titlebar).

It's in a separate window, yes. I just find it a bit suspicious that the invalid cert code, which runs on a different thread, is trying to put up it's dialog at the point where we're crashing

(Following up comment #6) > All the coreui.apple.com stuff seems to be from Apple. But grepping > the /System/Library/Frameworks directory on my (fully updated) OS X > 10.5.5 installation for "CUISharedArtReader" returns no hits. I found the (undocumented) CoreUI framework -- it's in /System/Library/PrivateFrameworks/. > Have you installed one or more Apple "extras" (in your home > directory or at the OS level)? So this question is no longer relevant (I think). > Dave, have you customized Thunderbird's display in some way? But this one is definitely still relevant. I'm looking for OS-level customizations.

(In reply to comment #9) > I just find it a bit suspicious that the invalid cert code, which > runs on a different thread, is trying to put up it's dialog at the > point where we're crashing Interesting that the invalid cert code runs on a different thread. But the crash happens on the main thread, and happens deep in OS code (code that (I think) draws part of the window's OS-level chrome).

Actually, I now suspect the crash happens while the OS is trying to read a resource from the Shredder bundle (a resource that it will use to draw part of the nss dialog's OS-level chrome). Could there be a problem with that resource (whatever it is)? What made me think this is a crash stack (in an unrelated app) posted at http://www.abyssoft.com/software/teleport/forums/viewtopic.php?p=1579&sid=2d3008ad5e1815e2ac821f6f3d14377a That crash is clearly different. But it shows that CUISharedArtReader::Setup() can look into the current app's bundle.

The obvious next question is, is there an easy way to make an nss dialog about an invalid/mismatched domain cert appear (easier than this bug's STR)?

https://sf.net/ triggers mismatched cert. it's the standard testcase.

ah, thx, timeless, I'd been looking for that for comparison purposes for an other bug. But it doesn't help for this bug in TB - TB is still using the old nss dialogs. I see these with my mac build because my isp has a domain mismatch in their cert. This dialog doesn't crash for me, and I don't know for sure that's why justdave is crashing; it's just a suspicious coincidence. If he could tweak his settings so that the imap count with the cert mismatch doesn't check for new mail on startup, or select the inbox on startup, it would be interesting to see if the crash went away.

(Following up comment #12) Here's one way you might only crash some of the time reading a resource from the Shredder bundle. It's a bit far-fetched ... but possible: What if the OS were trying to load the resource before nsAppShell::Init() was called, and therefore before the bundle's nib was loaded? This kind of crash would only happen as Shredder is starting up. But it's conceivable that if the code which displays the offending window (possibly an nss dialog) is triggered by code running on a secondary thread, this could happen before the app (Shredder) is fully initialized (before nsAppShell::Init() is called).

I have made no customizations that I know of to the OS (unless you count installing drivers for an EVDO modem). And as stated, using a separate profile eliminates the crash. Removing the extensions and chrome directories from my profile doesn't make it go away. It's just strange.

Actually my scenario from comment #16, though a bit far-fetched, is easily testable. All you need to do is add a printf() statement to nsAppShell::Init() (in widget/src/cocoa/nsAppShell.mm) and rebuild. Then go through your STR and note whether the crash happens before or after the call to nsAppShell::Init().

(In reply to comment #18) > Actually my scenario from comment #16, though a bit far-fetched, is > easily testable. All you need to do is add a printf() statement to > nsAppShell::Init() (in widget/src/cocoa/nsAppShell.mm) and rebuild. > Then go through your STR and note whether the crash happens before or > after the call to nsAppShell::Init(). nsAppShell::Init() gets called well before the place where it normally crashed. However, I got prompted that a script was unresponsive this time. I clicked Debug, it spewed a backtrace into the console, then kept going, and I got a front end window (looked funny because I launched in safe mode). I quit and re-launched without safe mode, and everything works. Interesting. I have profile backups of course, and since I've been using this profile on the old Mac still for a while, I'll need to re-restore that one (the local copy on the new MBP is a little old) before I start using it again. So good chance I'll get another shot at reproducing this again. Console log of both runs attached.

OK, with a freshly-restored backup of the profile off the old Mac (just a note - one difference from previous versions is that my mozilla.com imap account is set not to check on startup on the old Mac now, since I've been using that account on a new profile on the new Mac recently), I got the same behavior, it gave me the unresponsive script dialog, I opted to continue this time. It gave me a UI window, and the UI was responsive, except that most of the folder icons were missing, and it refused to actually check mail if I asked it to. I quit and re-launched the app (from the command line again), this time it launched very quickly, but again had most folder icons missing, and refused to check mail. I quit the app one more time, this time launched it from Finder, the app launched quickly, the folder icons were all present, and it began checking for new mail immediately. I went to the mozilla.com account, re-enabled it, and told it to check mail, discovered it had tossed the offline cache, and it proceeded to spend the next hour and a half (time guestimated, it's still going as I type this) downloading my 1.6 GB of mail off the server. I did a quick diff against the backup, and the following files got touched since the backup was restored: (not counting Mail and ImapMail folders) compatibility.ini compreg.dat cookies.sqlite-journal extensions.cache extensions.ini extensions.rdf folderTree.json global-messages-sb.sqlite panacea.dat prefs.js xpti.dat The change to prefs.js was this: -user_pref("mailnews.ui.threadpane.version", 6); +user_pref("mailnews.ui.threadpane.version", 7); Gavin tells me the way we decide whether the unresponsive script dialog gets presented changed earlier today (and my checkout that I built from was new enough to pick it up). I suppose it's also possible that something in threadpane UI version 7 is more forgiving or better at repairing whatever was ailing my profile than version 6 was? So the good news is I'm finally up and running with email on my new MacBook Pro, which means I can finally wipe and reload the old one without fear, and this problem is no longer blocking me from getting full use out of my new laptop. I am of course saving backup copies of these profiles in various states and will be more than happy to continue experimenting if anyone still wants to try to determine the root cause.

The mailnews.ui.threadpane.version preference is set/actioned on approximately here: http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#943 So all we should be doing in going from 6 -> 7 is to mark all your imap folders as offline.

(In reply to comment #19) I'm still pretty sure (from the evidence in comment #0's crash log) that the crash happens while the OS is drawing OS-level chrome (possibly in the titlebar) in some window (a browser window or a dialog), and while it's reading from a local file. The local file might be in Shredder's "bundle", or it might be in a profile.

I don't know if the crash is always in CFRelease, but adding to the summary anyway.

Other CFRelease crashes http://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=CFRelease&date=&range_value=4&range_unit=weeks&do_query=1&signature=CFRelease mostly 3.0

The single crash in that range (bp-c0614203-b29c-4f2b-9d29-e44852100201) seems totally unrelated. Which isn't surprising, since CFRelease is the equivalent of nsISupports::Release() -- crashes with CFRelease as a signature will almost always be unrelated.

Is it safe close this bug, aka say it is unlikely to get additional useful progress, by further diagnosis of the known facts above?

I'd say if the original problem (the one reported in comment #0) no longer happens, we should close this WORKSFORME.

I've got no way to reproduce it at this point. All that stuff is long gone.

Thanks for the update. Incomplete seems appropriate.