What's it all about, Alfie?

This morning I noticed that Google Chrome dev 13.0.782.1 was out with some nice incremental features. I'm not a big printer, but I'm sure there are a lot of folks are, and that's important to them. Certainly, the comments are excited about the printing. Also the 2D acceleration looks to be nice - can't hurt, that's sure. It's nice and fast, which is what you'd expect from a peck of engineers, and as long as it keeps moving in that direction, that's great.

[3/3] UPDATE: that didn't take long. Already 13.0.782.4 is out. Must have been a pretty serious problem to issue a new release so soon. Well... glad they responded so quickly.

Today I've learned a very valuable lesson today: TCMalloc really doesn't have bugs, but it sure looks like it does and stack traces can be very deceptive at times. I have been getting a series of segmentation faults on some code and the backtrace was always in about the same state, and was saying something like this:

  #0  0x0002aac607b388a in tcmalloc::ThreadCache::ReleaseToCentralCache
        (tcmalloc::ThreadCache::FreeList*, unsigned long, int) ()
        from /usr/lib/libtcmalloc.so
  #1  0x0002aac607b3cf7 in tcmalloc::ThreadCache::Scavenge() ()
        from /usr/lib/libtcmalloc.so
  ...

The lesson learned, after googling this backtrace, is that TCMalloc doesn't have bugs, it's just too stable. However, it's not able to properly trap double-frees, or illegal frees, so when it finds that it's structures are corrupted, it bails out and appears to have a bug, when the problem was really in the 'hosting' code. Meaning: user error.

So I started looking at what was leading up to this in the backtrace. I worked on this for the better part of a day, and reformulated the code several times. In the end, I was totally unable to correct the problem. Very frustrating.

Then it hit me - maybe it wasn't in the calling stack? After all, this same code was working quite well for months in other apps. This was the 'Eureka moment' for this guy... it wasn't the call stack at all - it was somewhere else in the code. So I started grepping for all the 'new' and 'delete' instances in the code. Sure enough... I found a few problems.

It's so easy for junior guys to miss these things, and they did. I only look for them because I've been bitten so badly (like this) so many times - it's the first thing I do when building a class with heap support - make the allocations and deallocations match. No two ways about it.

I'm hoping that this fixes these problems, and it's looking good so far. Just awfully tricky when the bug is nowhere in the stack. Wild.

Today I had to do a little hammering on my new NBBO engine because I found a few problems in what it was doing. I wasn't properly filtering out bad data from the NBBO calculation, and that needed to change. Plus, I wanted to add a simple method to force a recalc of the NBBO because I was seeing bad data get "stuck" in the engine, and wanted to have some way to clear it out. Finally, I introduced a bug in the forced recalc that I had to find - silly cut-n-paste bug, but easily found.

But the nice change I did was to realize that the exchange data for the instruments could skip having the security key - a textual representation of the security, and just use the security ID - a 128-bit number that was equivalent to the security key. The difference was that I could skip the conversion from the key to the ID, and that saved an amazing 33%. I was able to get my times down to about 22 μsec - just amazing.

Consequently, the engine takes 33% less CPU and that directly translates to more feeds on the box. That's always a good thing. Very nice fix/change.

This morning I saw a tweet that Acorn 3.0.2 was out, so I downloaded the update right away. There are quite a few nice features in this release, mostly bug fixes and performance enhancements, but hey, those are nice too. Still the best alternative to the heavyweight Photoshop there is on the Mac. Love it.