So... I figured out the sporadic crashing problem in TuneTagger. It turns out that something was being released one time too many, but not the something that I originally suspected. When approving lyrics through the TuneTagger interface and transferring the lyrics to iTunes, TuneTagger has an internal global variable that stores the current lyrics. This wasn't being retained when transferring lyrics.

So what ended up happening is that on the next refresh of song info (when the song changed), the proposedLyricsTextField was releasing the reference to the old lyrics when replacing the view with the new lyrics, and since the previous lyrics weren't originally retained, it was causing a crash at that point. (This is why it crashed even when setting the text field to display a static piece of text.)

What allowed me to pin down the problem was the fact that I finally was able to reliably reproduce the problem: I noticed that it was occurring on the next song change after transferring lyrics over. It was a delayed memory management problem, that also often happens if you autorelease objects in the wrong places.

Moral of the story: make sure you watch out for objects that you need to retain.

Alternate moral: develop for Leopard and up only -- that is, use automatic garbage collection and dispense with the manual memory management. Mmm.. I can't wait to be able to assume a minimum Mac OS X version of 10.5 just for that one feature.

---

I also neglected to mention something in the last entry; going to the Leopard Tech Talk allowed me to finally understand another long-standing problem that I've had for a while. I noted this issue at the end of an entry I wrote a year ago:

Unfortunately, in my experience, I've found that AppleScript in Mac OS X is much more unreliable compared to AppleScript on the Classic Mac OS. Script Editor throws up weird errors like this that I can't seem to figure out, and it also borks in totally lame situations. For example, sometimes I like to "cheat" and create a complicated command such as set ooga to text item 5 of (first item of (get selection of application "Finder") as string) and AppleScript borks on it. However if you split it up into lines like so...

set ooga to (get selection of application "Finder")
set booga to first item of ooga as string
set blah to text item 5 of booga

... then the AppleScript works. I'm not talking specifically about these lines of code, but I'm demonstrating a similar situation to those when AppleScript sometimes borks. There should be no difference whatsoever between the single line and the split lines, but sometimes it seems the split lines are necessary. Has anybody else been having similar difficulties with AppleScript on Mac OS X?

It was actually kind of funny how I learned the answer. Soghoian was demonstrating how to implement AppleScript support in one's application, and he was writing an AppleScript to demonstrate the app's newfound scriptability. In doing so, I noticed the same problem occurred: he wrote a long command that referenced multiple items all at once on the same line. He compiled and ran the script, and it borked on that complicated line. Then, he split up the line into two (similarly to how I split the line up into three above), and compiled and ran the script again. It worked!

I went up to him after the presentation and asked him why. Turns out, AppleScript isn't getting the implied "get"s in the complicated command. So something like set ooga to text item 5 of (first item of (select of application "Finder") as string) will probably bork. The solution, according to Soghoian, is to explicitly add in the "get"s, like so: set ooga to (get text item 5 of (get first item of (get selection of application "Finder") as string)

Rrrrrr, that problem has been bugging me for so long when I create AppleScripts. Nice to finally know the reason why. Hopefully someone else will find that useful as well.