Update: I’ve put up a new version of the importer that has a much longer timeout when waiting for Quicktime to export each movie.

Right now Quicksilver is using roughly 235MB of Real Memory. Running vmmap on it tells me that almost all of that memory is in the malloc zone, and the vast majority of that malloced memory are freed blocks. So my question is why are my multitudes of freed MALLOC_TINY pages not being reclaimed by the system?

So if you’re using Safari 3.0, or if you’re Czech, go ahead and download SafariSource. If you’re using Safari 2.x, please let me know it still works as I can’t test that with 3.0 installed.

pmTool, the process run by Activity Monitor to actually collect stats, appears to leak memory. If I leave Activity Monitor running for a good period of time, when I check up on it pmTool is often using over 100MiB of Real Memory.

I just checked my laptop, pmTool was using over 100MiB of Real Memory. Right now on my desktop it’s using 41MiB of Real Memory, but I don’t remember how long it’s been running for. I also believe a good deal of memory is currently paged out.

After checking up on it, pmTool on my desktop has a Private Memory size of 91MiB.

If I run leaks on pmTool on my desktop, I see 27931 leaks for 85799936 total leaked bytes, which works out to about 81.8MiB of leaked memory. All but 2 of these leaks appear to be blocks of memory of size 3072 that start with '?\0'.

In any case, this seems to be a pretty significant leak in pmTool.

A highly non-scientific test shows it to be adding one new leak every time the UI in Activity Monitor updates (default is every 2 seconds). So if you haven’t changed the update frequency then pmTool will leak 3KiB of memory every 2 seconds.

That’s a lot.

I haven’t noticed pmTool taking more than about 100MiB of Real Memory so far, but I never thought to check Private Memory until now so it may have simply been paging out a lot of leaks. If my calculations are correct, every 24 hours pmTool will have leaked 126.6MiB.

If you keep Activity Monitor running constantly like I do, you may want to check what your current memory usage is. If you see anything close to what I am, you may want to re-evaluate the importance of Activity Monitor (or set up a cron job to periodically restart Activity Monitor). On the other hand if you’re not seeing a leak problem I’d be interested to hear the details of your system (I’m currently running OS X 10.4.8). I’m not entirely certain whether this leak is Apple’s fault or whether one of the myriad customizations to my system is somehow causing this. As far as I know none of the hacks I use that inject into other code processes affect pmTool (seeing as how it’s not an AppKit application, so it doesn’t load Input Managers, and it’s run as root so it won’t be affected by anything that tries code injection), so this seems likely to be Apple’s fault, but if so I’m really surprised that they haven’t fixed it.

Update: I just checked the current memory usage of pmTool. I haven’t restarted it in at least a day, and yet it was listing a reasonable 1.2MiB of Real memory, and roughly the same Private Memory. This is the memory usage I’d want it to have, and yet completely different than the observed behaviour I documented in this post. I double-checked and the memory usage on my laptop was up to 55MiB. I wish I had thought of running leaks on pmTool when I saw this, but instead I quit and relaunched Activity Monitor, and immediately the leaky behaviour came back.

Update 2: I feel silly now. I completely forgot I’d set up a root crontab entry with @hourly killall pmTool to minimize the leak. That’s why it was showing such a small memory usage.

Update 3: I just got a brand new 2GHz Core 2 Duo MacBook, running 10.4.8 with the latest security update (i.e. the same OS as my iMac), and quite mysteriously, this leak isn’t showing itself. pmTool has a respectable 960KiB of Real memory usage, and no leaks. I can’t explain it.

Anyway, the machine is pretty sweet. It’s blazing fast and, luckily, World of Warcraft went Universal yesterday so I could try it out. I can’t turn everything up and have it be smooth, but I can turn the graphics settings higher than I could on my Desktop.

You can find pictures of it being unpacked here.

Anyway, I flew out here 2 days ago and am staying (for the short-term) with my older brother Rick, who works at Apple. I’m looking into getting an apartment with my coworker (his name is Tristan), but we need to find something appropriate first. In any case, the work here looks to be quite interesting and enjoyable - last night Tristan and I stayed until, I believe, 9:30 PM. Granted, I was just customizing my computer to have all the things I want/need on it, but he was actually doing some work.

For those of you who use the Yahoo! Instant Messenger network, you’ll be happy to learn that the project I’m working on is the Yahoo! Instant Messenger client. However, I think that’s all I can tell you, so don’t bother asking for details.

This update was a real pain to do. I ran into a memory corruption bug that I spent hours trying to track down. A couple hours ago I finally discovered the cause. I was using a header file class-dumped from Jaguar’s AppKit and apparently Panther added 2 new ivars to NSPreferencesModule. What I didn’t expect was that my definition of NSPreferencesModule was taking precedence over AppKit’s definition, so when I allocated the memory for my subclass it wasn’t large enough and whenever those 2 extra ivars were written to it was writing to memory that wasn’t owned by my instance and that was the memory corruption. Simply class-dumping a new header file and using that magically solved the problem.

Anyway, enjoy :)

What is it, you ask? It’s an open-source centralized notification system for Mac OS X applications, allowing applications to have consistent, non-interfering notifications that are fully user-customizable with very little effort. And it supports a display plugin architecture which means that if one person creates a new display for Growl notifications, all applications can benefit. Only a small number of applications currently support Growl, but that number is growing.

One of the really nice things about Growl is the level of developer support it has. It’s possible to use Growl from Cocoa, Carbon, python, perl, tcl, and AppleScript, and there’s nothing to stop bindings for other languages from being created.

Anyway, if you want to see some docs or screenshots, just head on over to their web site