Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pudge (1)

  (email not shown publicly)
AOL IM: Crimethnk (Add Buddy, Send Message)

I run this joint, see?

Journal of pudge (1)

Monday April 26, 2004
04:41 PM


[ #18499 ]

In Mac OS, one would get the data out of an Apple event AEDesc object by merely returning the dataHandle portion of the struct. It's a Handle object.

In Mac OS X, however, one must copy the data to a new Handle object.

So when porting Mac::Carbon to Mac OS X, I made the change, and didn't think about the fact that in Mac OS X, the caller would now be responsible for disposing the Handle object that was returned. Yikes. Memory leaks abound.

Most Mac::Carbon programs I use don't really stick around. Even when they do, such as with my happening script that sets my iChat status, the amount of data that was being leaked was pretty small. The name and artist of the current track, etc.

But then I added functionality to the script so it would change my iChat account icon to the album cover of the track I am listening to. So instead of 100 bytes or so, I was now leaking as much as 250K or so, every 10 seconds. That adds up pretty quick.

I have a temporary fix (manually disposing of the Handle object), but I need a more permanent solution. Matthias (original author of Mac::AppleEvents, MacPerl, etc.) gave me some good ideas, and I'll be working on it soon.

I think I'll use some XS tricks to make a new data type, XAEDesc, which will contain both the AEDesc and a Handle, so instead of creating a Handle each time, the data is transferred to and from the Handle in the XAEDesc. When the AEDesc is destroyed, its corresponding Handle will be disposed of automatically, like it was previously (by modifying AEDisposeDesc to also call DisposeHandle).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.