iTunes is one of a few Apple-provided applications that prevent you from attaching a debugger. This can be problematic if you are, say, developing an iTunes visualizer. iTunes accomplishes this by calling ptrace(PT_DENY_ATTACH, 0, 0, 0), which prevents future attempts at tracing the process. Debuggers like gdb use ptrace to control the process they debug. Luckily, there's a way to intercept the ptrace-call before it completes, simply by starting iTunes in the debugger. Let's see what happens when we run iTunes from gdb in Terminal, without doing anything:
[#] cd /Applications/iTunes.app/Contents/MacOS/ [#] gdb ./iTunes gdb shows some license info (gdb) run Starting program: /Applications/iTunes.app/Contents/MacOS/iTunes Reading symbols for shared libraries ... done Program exited with code 055.
Not quite what we want. Let's see what happens when we put a breakpoint on ptrace before starting iTunes:
(gdb) br ptrace Breakpoint 1 at 0x7fff90592d14 (gdb) run Starting program: /Applications/iTunes.app/Contents/MacOS/iTunes Reading symbols for shared libraries . done Breakpoint 1, 0x00007fff90592d14 in ptrace () (gdb)
We're stopped at the entry to the ptrace() function. Now, at this point we have two options: We can force the function to return, setting its return value to 0 to indicate no error, or we can modify the arguments to the ptrace call. Either way works, but this post will demonstrate the latter approach.
We know that iTunes calls ptrace with PT_DENY_ATTACH as its argument. Looking at the ptrace header file, we discover that PT_DENY_ATTACH corresponds to the value 31:
From /usr/include/sys/ptrace.h: #define PT_DENY_ATTACH 31
Now, let's look at the contents of the registers:
(gdb) info registers rax 0x24a0 9376 rbx 0x7fff5fc35120 140734800023840 rcx 0x0 0 rdx 0x0 0 rsi 0x24a0 9376 rdi 0x1f 31 Rest of register contents snipped
The register rdi looks promising. Let's try changing it to the value matching PT_DETACH:
(gdb) set $rdi=11 (gdb) info registers rax 0x24a0 9376 rbx 0x7fff5fc35120 140734800023840 rcx 0x0 0 rdx 0x0 0 rsi 0x24a0 9376 rdi 0xb 11 (gdb) continue Continuing. Reading symbols for shared libraries . done Symbols keep loading, and iTunes launches. And we're still attached!
So that seemed to work brilliantly. At this point, you can use the debugger as normal, pausing iTunes when you need to, getting backtraces, and catch errors in your visualizer. The only caveat is that detaching iTunes using gdb will probably hang, since we replaced PT_DENY_ATTACH with PT_DETACH earlier. This can be worked around by using the "return immediately" approach I alluded to earlier; doing this will be left as an exercise for the reader. To make gdb exit, you will probably have to kill it. As a final note, I should point out that this approach has only been tested on Lion (10.7), although I suspect it will work just as well in earlier releases of Mac OS X. Have fun!
Lion's release introduces a small but annoying bug that manifests in FolderGlance. If you have selected to show mounted volumes in either the context menu or the menu extra, you will get all mounted volumes, as well as a volume whose name consists of seemingly random characters:
This volume is actually the new "MobileBackups" volume, created and maintained by Time Machine. According to John Siracusa's review of Lion on Ars Technica, this volume is actually an NFS-mounted network volume, which is confirmed when running the mount-command:
/dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) localhost:/DOeN59ypHYcKHEzVPFLU0q on /Volumes/MobileBackups ...
So the mount path, "/Volumes/MobileBackups" has a nice, human-readable name, whereas the path to the network volume seems to be where things are getting screwed up. For some reason, FolderGlance picks the wrong part of the name to display. Why?
To support localized file-, application- and folder-names, FolderGlance filters any name it will display to users through a function called LSCopyDisplayNameForRef(). For most English users, this doesn't matter much, since display names and actual file names are usually the same. However, for international users it's an important feature; instead of seeing an unfamiliar directory structure (especially in home directories and when listing the contents of the /Applications folder), application and folder names will appear in their local language - at least where available.
It turns out that it's the use of the LSCopyDisplayNameForRef() function that causes this annoying UI issue in FolderGlance. Two out of the three APIs provided by Apple to convert paths to display names provide the desired name (MobileBackups), while the third returns an incorrect display name (the random character string). The two working APIs are:
Obviously, the non-working API is LSCopyDisplayNameForRef. I've submitted this bug to Apple as bug ID 9833110. While I wait for Apple to fix it, I've added some custom code to handle the case of /Volumes/MobileBackups, which is included in the just-released version 3.0.2 of FolderGlance. An option to hide this volume entirely will probably be added in the future. Code to see the behaviour of this bug is available here. You can compile it by executing the following command:
Apple released Mac OS X 10.7 Lion today, and I'm releasing FolderGlance 3.0.1. The new release brings a number of fixes and minor new features, but importantly, it also makes FolderGlance work with the new OS release from Apple. Other new features include a setting to turn the display of volumes in the menu extra on or off, and the ability to mount aliases to network volumes when mousing over such aliases in FolderGlance's menus with the Option-key held down.
There is currently one known bug with FolderGlance on Lion: It will display a very unfriendly name for the new "MobileBackups" volume created by Lion on portable Macs. This will hopefully be fixed in the next version of FolderGlance.
If you're curious as to how FolderGlance can continue working on Lion when Apple has disabled support for Scripting Additions, feel free to drop me a line or let me know in the comments.
I just saw some benchmarks over at Phoronix comparing Snow Leopard and the developer preview of Lion. One of the differences is that the Lion kernel boots in 64-bit mode by default. One of their benchmarks measures compile time, and the results indicate that a 64-bit kernel might boost the speed of compiling code. Noticing that my MacBook Pro was running the 32-bit version of the Snow Leopard kernel, I decided to run some informal tests myself.
My test-case was a full build of the FolderGlance code base. I timed the build with my iPhone, so the results are not completely accurate. However, barring any measurement inaccuracies, the results were quite good:
Pretty good for simply switching to the 64-bit kernel! In case you are wondering: Switching to the 64-bit kernel can be done by either holding down the 6 and 4 keys while your Mac is booting, or you can execute the following command from Terminal to make the change persistent:
sudo systemsetup -setkernelbootarchitecture x86_64
Read more here: http://support.apple.com/kb/HT3773
This got me wondering if I could speed up compiles further using additonal processes. Xcode defaults to using the same number of sub-processes as the number of cores your Mac has. My MacBook is of the Intel Core i7 variety, with two cores, 8 gigs of RAM and an SSD disk. I figured I might try to up the ante, since compiles are often I/O-bound rather than CPU-bound, although I was skeptical since my Mac has an SSD disk.
I configured Xcode to use 3, 4 and 8 subprocesses, instead of the default 2. You can set the number of processes Xcode uses from Terminal as follows:
defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4
These are the results I got (all on the 64-bit kernel):
So, for now I'll up the number of subprocesses Xcode uses to 4, since that seems to provide the best performance for this particular use case. The best number will also vary depending on the disk you use, how much memory you have available and the kind of code you are compiling.
Yesterday, I released FolderGlance 3.0 (along with a redesign of the Yellow Lemon Software website - though my blog will keep its current design for now). The new version has been a long time coming. I did an interview with MacTech last May, guesstimating that FolderGlance 3 would arrive "sometime this summer" - this summer being last summer. Well, it's here now, and I urge you to give it a go.
A screenshot of FolderGlance 3.0 previewing an image.
So, what's new? Well, the new version has two main new features, in addition to sporting a completely redesigned preference pane. The first is the new menu extra, which gives you access to custom folders, volumes and Spotlight search results from your menu bar. You can browse things as normal - the main difference is that the menu extra doesn't pick up the current selection from the Finder. Implementing the Spotight functionality - especially the user interface, believe it or not - was a very interesting challenge, and I'm not entirely certain that I've nailed it 100% yet, though at least for me, it works very well. My trials and tribulations implementing the text entry and menu item for this will hopefully be the subject of a future blog post (though, given my track record on predicting new versions of FolderGlance, it might take some time).
The other new feature which I'm really excited about is scripts. When Apple launched Snow Leopard, they also removed support for Contextual Menu Items. I managed to work around that limitation with FolderGlance, but I still wanted more options for customizing my menu beyond what could be done with Services. A step along that path is support for custom, context-sensitive scripts. Scripts in FolderGlance can operate on the current selection, the parent folder of the current selection, or on folders you browse to. FolderGlance ships with two simple scripts, and an additional two sample scripts to demonstrate what you can do with the new support for scripts. Scripts that don't operate on the selection also work in the menu extra, by the way.
The first script simply calculates the total disk usage for items in the current selection. The C++ source code for this script is on the disk image, if you want to understand how it works or customize its output. The Open Terminal script is available in any folder you browse to, and lets you open a Terminal session with the working directory set to the folder you browsed to.
The two additional sample scripts, which are not installed by default, demonstrate how you can use FolderGlance's script support to build your own menu hierarchies in the Finder's context menu. If you do anything cool with this, feel free to let me know!
If you want to learn more about FolderGlance, check out the screencast, look at the screenshots or give it a go here: http://www.scsc.no/products/folderglance/
Enjoy the new version!
Spaces.. Spaces.. Spaces.. (Retired)
Jul 28: Running iTunes in a debugger (gdb)
Jul 25: The /Volumes/MobileBackups directory
Jul 20: FolderGlance 3.0.1 supports Lion
Mar 03: Quick tip: Speeding up Xcode compilations
Mar 02: FolderGlance 3.0
Jan 07: Making Universal Back Button work on 10.6.5 and later
Sep 03: Creating pthreads in C++ using pointers to member functions
May 31: Quickly open URLs in Terminal
May 31: Snow Leopard and automatically submitted Crash Reports
May 27: Universal Back Button released for Mac OS X
May 22: The 22 Megapixel Laptop
Feb 09: FolderGlance on MacUpdate Promo
Sep 28: FolderGlance 2.5.3 is out
Sep 21: FolderGlance 2.5.1 adds features and fixes bugs
Sep 16: FolderGlance 2.5 released!
Sep 10: Intriguing: Snow Leopard ships with the iPhone's multi-touch API built-in
Sep 03: FolderGlance and Snow Leopard
Mar 15: Fixing Keynote '08 and '09 to work with the Scripting Bridge
Feb 26: A website in an image
Feb 09: Display wall multi-touch
Feb 19: Spaces.. Spaces.. Spaces.. retires
Feb 08: How-to: Reverse engineering the Dock to fix Spaces
Jan 25: Interacting with wall-sized displays
Dec 20: Interesting Finder bug
Dec 06: Developing applications for the iPod touch (and the iPhone)
Nov 15: Spaces.. Spaces.. Spaces.. and 10.5.1
Nov 15: Thread creation using pthread_create() on Leopard
Nov 13: Spaces.. Spaces.. Spaces..
Nov 07: FolderGlance, Leopard and the More... menu
Nov 06: FolderGlance and Screen Sieve now also on Leopard!
Sep 16: Mysterious window server hangs