Software: January 2009 Archives

Occasionally programmers want to get a backtrace (the set of function calls that the program is currently in: A calls B, which calls C, which calls D, etc.) This is particularly useful for writing various kinds of instrumentation like memory checkers, profiling tools, etc. This is straightforward with a debugger, but that's not really convenient if there are a lot of events you want to get backtraces for. It's also possible to do this nonportably: if you know the way the compiler lays out the stack, you can grovel through memory and dig out the stack trace yourself, but that's a pain and requires reading a lot of documentation about the memory layout, so people typically don't bother.

Conveniently, if the program was compiled with GCC there's a much easier way. GCC has a builtin primitive that lets you get the frame pointer or return pointer address of any function in the call stack (documentation here.) Obviously, this is just the address, but you can then use dladdr() to extract the name of the function. Put together, you've got a backtrace. Note that this only gives you the function name and (with some work) the offset into the function. You'd need to grovel through the symbol table or something to actually figure out what line of source you were on. Still, that's information you didn't have before and is enough for a lot of purposes.

On FreeBSD, there's actually a library in ports called libexecinfo, which implements this trick. That's where I learned about it. Glibc also includes this as a native facility. I assume it works like this, but haven't bothered to examine the source.

I recently had to send my Macbook Air in for repair and as a precaution I burned most of my data off the hard drive. Of course, when it came back I wanted to restore some but not all of my data. I have Time Machine backups, but since I actually only want some of the data and I want new versions of the software, I decided to treat this as a new machine install. Naturally, I figured I could just use iTunes to sync my data off my iPhone. In principle this should work fine. In practice, not so much.

The first problem I had when I plugged things in and pressed sync is that iTunes decided not to actually copy my calendar, contacts, etc. off. After a few minutes I remembered that you have to actually frob some button in a dialog for each of these. Once I had that figured out I tried to sync it again and after asking me if I realized that I was massively changing the data on my computer (which, remember, knows nothing at this point) it just popped up the useless progress bar and spun. And spun. For hours. I tried this a few times with the same results. At this point I figured I had been bitten by the dreaded slow iPhone sync, and was all ready to start trolling my disk for crash files to delete, slaughter a rubber chicken, etc. when somehow I noticed that hiding under all my other windows was a dialog saying "hey, you know you're replacing the contacts list on your computer with the one on your iPhone, right". Clicking that dialog made everything proceed in a few seconds. Remind me again why that dialog isn't modal? The spinning progress bar isn't exactly the UI indicator you would ordinarily use to indicate that I needed to click on some button. For that matter, why do I need to click this dialog at all? I just installed the operating system: why wouldn't I want to copy stuff off my phone onto my totally empty calendar and contact list?

And just as mysteriously as it broke, Google Reader is now picking up all my posts from the Atom feed. This could be the result of anything from my upgrade fo MT 4.23 (Grrr!), my whining to friends who work for Google, or just random software frobbing. Incidentally, this illustrates an annoying feature of RSS-style blog reading: blogs just drop off the radar and the software doesn't always tell you (or even know, if there's some bug) that something is hosed, as opposed to authors just not writing anything. So your subscription list just rots.