Idle Time

The most significant behind-the-scenes change in Growl 1.1.5 is that we now build using the DWARF-with-dSYM debug symbol format.

Now, we distribute a fully-stripped executable for every release—even betas—and we keep the dSYM bundles on hand separately. The idea here is that we can use the dSYM bundles to obtain symbolic information (function name, filename, and line number) for the bare addresses in users’ crash logs.

Unfortunately, there are no good tools for symbolicating Mac OS X crash logs. If this were an iPhone app, we could just drag the crash logs into the Xcode Organizer window, but Xcode doesn’t do this for Mac crash logs.

I tried all the other tools as well, and every one of them had one of two problems:

1. Didn’t work at all
2. Needed the dSYM bundle and main bundle to be next to each other on disk

#2 is not a deal-breaker, but it is a hassle.

So I wrote my own symbolication tool.

The Symbolicator is a Python script that:

1. Reads in a crash log.
2. Finds the necessary dSYM bundles using Spotlight. (This means that you can put the dSYM bundles anywhere you want, and as long as Spotlight can find them, the Symbolicator will be able to use them.)
3. Uses dwarfdump to extract the relevant symbol information.
4. Replaces the address offsets with the symbol information (just like CrashReporter does when it has debug symbols to work with).
5. Writes the symbolicated log to stdout.

Use it like this:

% symbolicator < unsymbolicated.crash > symbolicated.crash

Or use ThisService to make a service out of it.

If you want to see it in action right now, download Growl 1.1.5b1 and the corresponding dSYM bundles from the Growl beta page. Make Growl crash (killall -TRAP works well), then unpack the bundles and use the Symbolicator on the crash log. (If you unpack the bundles first, CrashReporter will symbolicate the log before you even get to it. Handy, unless you’re trying to test the Symbolicator. ☺)

To make this work on your own app, follow the instructions in the aforementioned ADC article, then make sure you archive the dSYM bundles for every release, including betas. On Growl, I added code to our Release Makefile for this.

Note: If your app is closed-source, you should not put your dSYM bundles on your website, since the debug symbols are arguably trade secrets (information about your source code). Keep them locally, perhaps on a flash-memory drive. Disclaimer: IANAL.

Add this to your ~/.hgrc file:

[hooks]
changegroup.growl = ((echo "$HG_URL" | grep -vF 'file:' > /dev/null) && growlnotify -n Mercurial 'Pull successful' -m "Pulled at least $(hg log --template='\n' -r$HG_NODE:tip | wc -l | sed -e 's/ //g') changesets from $HG_URL") || true
outgoing.growl = (test "x$HG_URL" '!=' 'x' && growlnotify -n Mercurial 'Push successful' -m "Pushed to $HG_URL") || true

It’s not perfect: Both notifications share the same notification name. As long as that isn’t a problem, this works fine.

The problem

The WebKit framework that comes with Safari 4 enforces a restriction on calling WebKit from a secondary thread.

GrowlMail accesses message contents on a secondary thread because they may not be in yet. Accessing message contents can result in a call to WebKit. That results in a crash with the new WebKit.

The fix (section added 2009-04-19, updated 2009-06-22 for the 1.1.5 release)

Download Growl 1.1.5 and install GrowlMail 1.1.5.
(Make sure you install GrowlMail specifically! The Growl Installer package does not include GrowlMail or any of the other Extras.)

The workaround

UPDATE 2009-06-22: You don’t need to do this anymore. Install GrowlMail 1.1.5 instead.

If you’re fast or can easily turn off your internet connection first, go to GrowlMail’s Preferences and set GrowlMail to summary mode. (You might also try putting Mail into Offline mode immediately after launching it until you’ve made this change.)

1. Go to Mail’s Preferences.
2. Click on the chevron button at the far right end of the toolbar.
3. Click on GrowlMail.
4. Choose the second of the three radio buttons: “Show a summary of received emails”.

You can then go back into online mode/turn your internet connection back on/rest easy.

The other way to do it is to run this command in a terminal window:

defaults write com.apple.mail GMSummaryMode -int 2

Ordinarily, I’d tell you to quit Mail first, but since Mail will unexpectedly quit the first time tries to Growl about a new mail message, I don’t think I need to bother. ☺

The fix

We’re not sure about that yet.

The problem is that when Mail adds a new message to your library, it may not have fully downloaded it yet. (You can see this yourself sometimes when your internet connection is slow or under heavy load: You’ll click on a message and see a “Loading” screen in the preview pane.)

When that happens, if we try to get the message body on the main thread, it blocks the UI until the body arrives. So we do it on a secondary thread instead. That’s now a problem.

The ideal fix is that we find a way to determine whether the body has come in yet. If it hasn’t, we could set a timer for a few seconds, then check again then and post a notification with “body not loaded yet” if it’s still not in.

Another fix I would consider is simply killing the feature that shows the message body in the notification. I’m sure a lot of you like it, but if it breaks the app and there’s no fix, then it has to go.

UPDATE 2009-02-25: As it turns out, we had most of the above fix in already (except that we were using a delay, not a timer—not a problem, since it’s on its own thread). So the fix was simply to move most of the code to the main thread. I’ve done that and it works. The relevant patches are pending review; if I hear nothing bad about them from the other developers by tomorrow, I’ll make them permanent commits and push them to both repositories, where they will be part of 1.1.5.

Other points

This is not a bug in WebKit. Strictly speaking, it’s not a bug in GrowlMail, either, because it’s not like we’re disobeying the documentation for Mail’s API (there is none!).

Apple changed WebKit to throw this exception, and GrowlMail doesn’t catch it. As far as I’m concerned, it’s GrowlMail’s fault and we’re the ones who need to fix it.

Timeline? No idea. I do intend to have this fix in for 1.1.5, since Safari 4 will probably be either out or coming Real Soon Now by then. (This among other important fixes, such as the off-by-two error in the Growl prefpane.)

UPDATE 2009-06-22: The fix is in GrowlMail 1.1.5, which we released on 2009-06-16.

I just released version 1.1.3 of Growl. Some highlights from the version history:

• Worked around conflict with Logitech Control Center 2.4, and implemented countermeasures in case another input-manager hack in the future has the same bug
• Show notifications on every Space (Leopard)
• Rewrote GrowlMail to fix conflict between it and Leopard, and make it much more robust for the future
• Updated GrowlSafari to work with Safari 3.0 and later (thanks to Ben Willmore)
• Fixed growlnotify to actually send the notification on Leopard
• Fixed a hang on changing the default display
• Fixed displaying a close widget on mouse-over

Those aren’t the only improvements, but they’re the most major. Growl and its extras are finally completely Leopard-ready.

You can download 1.1.3 either from the About tab in the Growl preference pane, or from the website.

In other news, this is my first release as the Lead Developer of Growl. I’m replacing Brian Ganninger, who was (IIRC) Lead Developer for the entire 1.1 series. Let us all thank him for his excellent work, and wish him well for the future.

Since 0.7, Growl has been able to detect a registration dictionary in your application when your app launches—all you have to do is put it in a file with a certain name inside your app bundle. We call this feature auto-discovery or auto-registration.

I don’t think people have been taking much advantage of this feature, though, for two reasons:

1. We didn’t mention it in the docs. (This would be the major reason.)
2. There was no handy-dandy editor to quickly bash out a registration dictionary file.

Sure, we can all use Property List Editor, but that’s not a tool honed to the purpose. You have to rifle through GrowlDefines.h to find all the different keys you can use in the dictionary (the docs only cover the most basic set).

Well, now there’s a tool honed to the purpose.

Here’s beta 1 of the Growl Registration Dictionary Editor. I invite you to try it. Obvious things worth doing:

• Creating new reg dicts
• Editing existing ones
• Importing a reg dict from your saved tickets (great for porting your existing app to use auto-reg!)

Feedback will be appreciated. If you’re subscribed to the Growl discussion list, you can send it there; if not, comments here are OK.

The source for the GRDE is in the Growl source repository.

If this announcement looks familiar to you, don’t worry; you’re not going crazy. I posted a similar message to the Growl discussion list, then decided to edit it a bit and post it here, since I know that at least several of you are Growl framework users who can put this app to good use.

pngout \        %~/Projects/@otherpeoplesprojects/growl/trunk/Core/Resources(0)
> NotifyOSX.growlStyle/Contents/Resources/sidetitle.png 
 In:                             NotifyOSX.growlStyle/Contents/Resources/sidetitle.png
 In:   29644 bytes
Out:                             NotifyOSX.growlStyle/Contents/Resources/sidetitle.png
Out:     527 bytes               
Chg:  -29117 bytes (  1% of original)