As many of my readers probably already know, a core dump is an image of the contents of a programs memory. Generally core dumps are created when a program fails in a particularly catastrophic way, such as a segmentation fault. Core dumps help programmers find out what lead to the failure. Usually it’s easy to get a core dump, you just do a kill -11 of the process ID, faking a segfault. This takes down the program and writes a core dump.

Unfortunately since core dumps aren’t useful to non programmers, the environment on OSX by default does not make them, even when there are segmentation faults. One can change this for a given shell or process or login session using the ulimit command or the associated syscalls, but Murphy was with me today and so ecto was not running with such a setting. It is possible to change the setting of a running process by connecting with a debugger like gdb and making the right syscall, but that felt a little risky, since if I messed it up the process would be gone, whether I got a core dump or not.

Instead, let’s figure out how to not kill the process at all, doing the work of taking the memory snapshot ourselves. This should be possible with modern process inspection APIs. The book you want for this is Mac OSX Internals. I have a copy, and was all set to begin some deep yak shaving figuring all this out. However, the book saw me coming, and already laid out an example in detail, called Process Photography.

So, if you want to know a lot more about making your own core dump utility, you can read that post. Or if you are still with me because you just want to know how to recover a blog post, then go there and download gcore-1.3.tar.gz at the end of the post. Untar it and compile your gcore utility. Now you can create a core dump by running gcore -c ecto.core PID. If your experience is like mine, this will generate a 1.3 gigabyte core file, because modern programs are not shy about using memory, virtual and otherwise.

Now, this 1.3 gigabyte core file contains everything from program text and mmaped files to active memory to freed memory that hasn’t been reused yet. It’s a vast expanse of stuff you don’t need, must of it binary. Luckily, most programs will just store textual content as ASCII or UTF8. Assuming you were writing English, then the strings utility will be sufficient to find your text. So you can run strings ecto.core > ecto.strings. This will generate another large file (64 megs this time, not 1.3 gigs) with just the ascii string data from your programs memory. Still a lot to wade through, so I use grep -i to look for uncommon words in my post, and less to be able to page around the file quickly.

I wish that the story had a happy ending, but after all that I found that the ecto memory space contained a dozen copies of my post, but all of them were the truncated version that it had posted on my blog, rather than the actual text I wrote. So you will have to wait until next week (or at least tomorrow) to learn what I had to say about house renovation.

As far as that goal goes, I think the switch has been a rousing success. In non-development activities (eg, web, email, calendar, documents) it has been a significant improvement. The tools I’m finding myself using include:

• Firefox – Safari just isn’t good enough, and on the Intel processor Firefox is plenty fast
• Terminal.app – In preference to X11.app and xterm, because it is better integrated with everything else
• Mail.app (aka Apple Mail) – Because as part of the switch I’m going to stop hacking my mail client and see how the other 90% of the population lives. Thus far, using a less featureful mail client has been a success for spending less time with email thanks to unsubscribing from things.
• Adium – This is the best graphical IM client I’ve ever seen.
• iCal – The Apple calendaring tool is adequate, though I think I may end up switching to something with Exchange support, as work moves in that direction.
• iTunes – Of course, this is a huge improvement over anything on Linux, particularly for synching with my iPod.
• Microsoft Office – I’d considered other alternatives, but the MacBook came with office preinstalled, and once I had it easily available (instead of in VMware) I couldn’t say no.
• NetNewsWire Lite - A feed reader that is much better than bloglines. I haven’t done much with the NewsGator integration, which might be interesting. And I haven’t seen a reason to buy the non-lite version.
• OmniGraffle – This is the best diagramming program I’ve ever used. Vastly better than anything on Linux, and much better than Visio.
• Parallels Desktop – Much nicer than VMware workstation on Linux. Well polished, and the Coherence feature is pretty hot.
• Desktop Manager - Free tool to implement virtual desktops. Does everything I want in this space.
• Quicksilver – This is basically a graphical commandl ine for the mac, accessible from anywhere. It’s very nice. Like screen, you have to try it to learn how much it will change your life.
• Visor – This is a cute hack that makes a Terminal only a keystroke away at any time. It’s a good complement to Quicksilver.
• MailActOn – This is a little tool that lets you define keybindings in Mail.app, mostly to refile mail into folders with a few keystrokes.
• TextMate – This is trying to replace emacs in my life. It’s a more mac-oriented text editor, with a pretty good feature set and good support for my emacs finger macros. But I may end up going back to emacs.
• Ecto – This is my latest addition. It’s a blogging client that I’m using to write this post. I’m not sure I’m in love with it enough to pay for it, though it is a bit nicer than Performancing, the Firefox plugin I had been using.

That’s about it for productivity tools. On development tools, I haven’t had to install very much:

• Apple developer tools – This comes on the standard install media, and gets you gcc, autoconf, and all the other things you would expect.
• SSH Agent – This is a version of the standard ssh-agent which integrates with the account management on OSX, so that you can use the agent from any application/shell in your login.
• SVK and Subversion – These are special builds for OSX, they seem to work well.
• Eclipse – Standard Eclipse is available for OSX
• MacPorts – This is a package system for getting various free tools. I currently only use it to get Cocoa Emacs.

So, that’s the enumeration of tools that I am using. Hopefully this is helpful to people. I may follow up on this with other posts about my experiences on OSX.

I will also shortly make a non-tools post.