Sunday, June 18th, 2006

Another Mac OS x86 benchmark...

So VP3 was crashing for someone when a particular Lua Script Plugin was used, but it was one of those cases where it was "sometimes". Blech. I hate that, it's super hard to debug.

So I got the script, tried it out, and sure enough... sometimes it crashed. Of course, never in the same place twice. Sometimes when the autorelease pool was emptied, sometimes in the Lua runtime, sometimes somewhere else. Obviously this was a job for Guard Malloc.

What's Guard Malloc? As Daniel Jalkut says, "This debugging aid slows your application to an absolute crawl as it intercepts all memory allocations and sticks protected memory pages between every malloc’d block. The end result? The vast majority of your “overrun the array” type bugs are caught dead in their tracks."

And slow it is. But it mostly works.

So I put some code in VP to wait 5 seconds after launch, and then to call the menu item that calls the script plugin, then quit the application. This way I wouldn't have to sit around and wait to call the menu item when VP launched. So I did that... launch VP, and wait. And wait. Guard Malloc is slow, remember? Then Bang! It found the bug. It was an overrun with a char* in the Lua bridge. Whoops. So I patch it (and I need to send along the fix to the main distribution), run VP again with Guard Malloc .. wait .. and wait .. and about 30-40 minutes later VP has gone through the whole test and all is good. Hurray!

Oh yea, what does this have to do with x86?

When I was running with Guard Malloc it was on my dual 2.7 G5. Out of curiosity I tried out the same test on my Intel iMac, and was in for a little shock- 2 minutes to complete. Wow. I put the bug back in place, just to make sure everything was the same. Yep- it stopped dead in its tracks where the overrun was. Put the fix back in ... 2:08 seconds. Yowzer. Why am I not using this as my main machine again?

-- posted 11:25 pm