Out of Cheese

I seem to be doing a bit more than my fair share of keeping junk off of 280 recently. About two weeks ago, I saw a huge plastic bag in my lane just before I was about to get off at De Anza. I thought about swerving around it, but there was a lot of traffic at the time and I figured hitting a plastic bag, no matter how big, shouldn’t do much damage. It stuck to my car until just before I turned into the parking lot at Apple, but the car was fine.

Today on my way home from Cupertino, I was changing lanes just before Bird Avenue and drove right into a barbecue grill in the right lane. That’s right — a barbecue grill. On 280. Maybe someone was a bit confused about the location of their Memorial Day barbecue and decided to have one a quarter-mile north of the Bird Ave. exit. Fortunately it was one of the little semi-portable apartment patio ones rather than the larger variety. I heard a ton of crunching, pulled over, and called AAA because the last time I was in a car that ran over something huge on the freeway, the car (Lilly’s then-new Mercedes) wasn’t drivable afterwards and needed some annoyingly expensive repairs. I was luckier than Lilly, though, since the driver of the truck that AAA sent out took a look at my car, pulled off an assortment of barbecue grill pieces, and said that it should be fine (albeit a bit scratched up front). I guess Hondas are built rather well.

Hopefully the CHP won’t start thinking that if they want any random junk cleaned off of 280 they can just wait till I drive near it….

I signed up for Apple’s slow-pitch summer softball league last week. I’d thought about playing for a while, and when someone asked if I wanted to play, I jumped at the opportunity. One catch — I hadn’t actually caught, thrown, or hit a ball in about fifteen years, and that was with baseball, not softball. The rules for this league imply that men will be better than women, but if you compare me to a woman with any reasonable amount of talent, I can make a mockery of those rules. If nothing else, I bet they expect that men can throw the ball all the way across the infield on the fly. I could do that with a baseball, but softballs are heavy!

Anyway, today was our first practice. I found out that after all those years, I can still mostly field ground balls, so that’s good. It’s especially good because I’d prefer to play a middle infield position over anything else, and fielding grounders is probably the most important part of that job. Outfield is out because I could never catch fly balls (we’ll see how I do on popups…probably poorly), third base is out because that’s a really long way to throw, first base requires me to field too well, and I’m certainly not about to pitch or catch. So if I end up being a shortstop, I think I’ll be at least OK in the field. Fortunately it isn’t a very competitive league, so OK, while not great, is good enough.

I also realized that I still can’t hit. I did manage to put the bat on just about every pitch I saw during batting practice — much better than I did in Little League — but there’s a big difference between making contact and hitting the ball solidly. Or hitting it far, for that matter. Most of my swings resulted in soft grounders to shortstop. (Hey, I bet I could field those!) I have a feeling that I’d be a lot better if I could take a few hours and face a couple hundred pitches. I wonder if there are any places around here that rent out indoor pitching machines for slow-pitch softball.

Unfortunately, I also realized that after all these years, I still break easily. I took a ground ball off my right thumb midway through the practice and kept playing, but now my thumb has a nice purply bruise on it. It still moves just fine, though, and it’s only a little bit sore, so I don’t think anything too serious is wrong with it. Hopefully it’ll be all better before our next practice.

Apple recently released Xcode 1.2 with the standard assortment of bug fixes and new features. One new feature is a bit hidden, though, and since I’ve only seen it mentioned elsewhere once, I figure it’s high time I let some other folks know. It’s called libgmalloc, or Guard Malloc if you’re into marketing terms.

libgmalloc is the best tool in existence for finding memory access bugs on Mac OS X. It’ll track down references to uninitialized memory, reading off the end of an array, accesses to freed memory, and so on. There’s a catch, though. When you run an application with libgmalloc, it’ll run significantly slower — perhaps two orders of magnitude slower — and it’ll use far more memory than it otherwise would. If you have a very fast system with tons of memory, you might be able to run various applications with it on a regular basis; if not, you might just test your application every so often.

First, though, you have to install libgmalloc. It’s a bit hidden. On the Xcode 1.2 Tools CD, you’ll find a Preview folder at the root level. Open that up and install the April2004LibgmallocPreview package. (No, I don’t know why there aren’t any spaces in the package name.)

Once it’s installed, running it is simple if you’re comfortable with the command line. Unfortunately, there’s no integration with Xcode yet. To use libgmalloc, you’ll have to set up two environment variables. I’ll use tcsh syntax here because that’s the shell I use; if you use bash, you’ll have to translate.

% setenv DYLD_FORCE_FLAT_NAMESPACE 1
% setenv DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.B.dylib

Now just run your application:

% ./myApp

and be very, very patient. If your application runs correctly (albeit slowly), congrats! You probably don’t have any memory stompers.

I frequently use libgmalloc from within gdb. That way I can debug my application immediately when it crashes due to an invalid memory access. Here’s how to do that:

% gdb myApp
gdb% set env DYLD_FORCE_FLAT_NAMESPACE 1
gdb% set env DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.B.dylib
gdb% run

Note that you want to set the environment variables from within gdb, rather than on the command line before you launch gdb. If you launch them before you launch gdb, you’ll be running gdb with libgmalloc, and it’ll also run a hundred times slower.

If you find crashes in Apple’s frameworks while running with libgmalloc, file bug reports! Mention that you were running with libgmalloc and the engineer who receives the bug will hopefully recognize that it’s unlikely that the crash was caused by a memory smasher in the application’s code.

Update: As of Tiger, DYLD_FORCE_FLAT_NAMESPACE is no longer required for libgmalloc. The only variable you have to set to use libgmalloc is DYLD_INSERT_LIBRARIES.

I saw a few mentions around the Internet today that Movable Type 3.0 has been released. Most folks were whining about pricing, but I’m not one to complain about anyone charging any amount for software — if it’s worth the price, I’ll buy it, and if it isn’t, I won’t. (Oh, and I think most of the software I buy is far underpriced based on the frequency with which I use it, but that probably makes me rather weird.)

In other words, whether I use MT 3.0 is far more likely to be dependent on its feature set than its price. But what is the feature set? In the few minutes I’ve spent trying to find out, I simply can’t determine what it has that’s different from 2.6, why SixApart thinks I should upgrade, or anything like that. There’s a “full feature list” that doesn’t discuss what’s new in 3.0, a “product info” page that also doesn’t mention any of that, and no mention whatsoever about the new features or changes between versions other than licensing on either movabletype.org or sixapart.com. I understand that the licensing change is a big deal for Six Apart, but I’m a current user of your software who’s thinking about buying your new version. You gotta tell me why it’s what I want.

I’m well aware, of course, that I could figure out all of this with a bit of googling. The point, though, is that shouldn’t be necessary.