Tidbits: Funny iSight Pic, Funny Out of Disk Space Error, RAB Friday VII/VIII

Sunday, 2005-10-09; 00:29:00

I've been sitting on this funny screenshot I took a while ago, when I was trying to capture the "malformed cursor frame" bug. It's kind of like that screenshot of the new design I took a while ago. Mmm... infinity is fun!

iChat to Infinity!

Here's another funny shot in the ongoing saga about how Mac OS X deals with the situation when the startup disk has run out of disk space. I previously posted a shot showing how iTunes deals with it (it "gracefully" tells you that the library file couldn't be saved because of a lack of disk space). The following screenshot is how Mac OS X deals with the lack of startup disk space with regards to virtual memory.

Out of Virtual Memory
It's in Italian, so I'll translate a bit. On the left it says, "The startup disk of Mac OS X doesn't have any free space for application memory. To avoid problems, quit some programs that you aren't using." On the right it says, "To free up memory, select an application and click on 'Force quit'" and "Try to close windows and delete documents from the startup disk."

This is basically an "Out of virtual memory" error for Mac OS X, and I wonder how many people other than me actually know about this dialog box (answer: only a select few Mac OS X engineers, I'd bet). If you close this window, it pops up again about three seconds later, so you can't really ignore it -- you can try to move it out of the way and then close it, but it comes back right in the middle of the screen, so it really does spur you to quit some applications. I suffered no ill effects from obeying the window after trying to ignore it a few times, though. :)

Still, though, I'd say that's a pretty graceful way of dealing with a lack of virtual memory, even if the window is cosmetically marred by the text running over on the button. I HAVE always wondered what a Mac OS X out of memory error would look like.


Yes, I know I flaked on RAB Friday last week, so I'll make it up this week with two really annoying bugs. The first is regarding the desktop: if you stuff an inordinate number of items on the desktop, the CPU usage of the process named "WindowServer" shoots up to 70-80%, and it stays there until you remove enough items from the desktop. drunkenbatman encountered it when he had 432 items on his desktop, but I encountered it when I had only 81 items on the desktop. This problem also seems to only happen in Tiger as I've had my desktop pretty full under previous versions of Mac OS X and WindowServer didn't cause any problems. So, if you have been having a similar CPU usage problem with WindowServer on Tiger, try to see if clearing your desktop fixes it. (Incidentally, this is a bug that could be construed as a feature -- it gives me a reason to keep my desktop clean. :) ) Bug number: 4293074.

The second bug is also Tiger-specific, and it concerns the new alias-burning functionality of the Finder. If you didn't know, Tiger changes the Finder burning functionality so that it doesn't create a full disk image of the CD/DVD you're trying to burn before actually burning it. With that method (which was used on Panther and earlier), you would have to have an amount of free space on your startup disk equal to the size of the disk you were trying to burn, which created problems when you were too late in realizing that the free space on your hard drive had dwindled too low. On Tiger, anything you drag to a blank CD in the Finder automatically gets aliased, but when the Finder goes to burn the files, it follows those aliases, and burns the actual files that they represent. In this way, the Finder directly burns CDs and DVDs without going through the intermediate step of creating a disk image.

The problem is that sometimes the aliases get screwed up, and it can cause a waste of a perfectly good blank CD or DVD if you're not paying close enough attention. If you drag a bunch of files at once to the blank CD/DVD in the Finder, it appears as if the aliases have been created correctly. However, sometimes the result is that you get a bunch of differently named aliases on the blank CD/DVD, but all of the aliases actually point to the same file! So when you burn the disk, you don't get nearly what you wanted on your CD/DVD.

This problem only manifests itself when you drag a bunch of files at once to the blank CD/DVD, meaning that the Finder is creating a bunch of aliases at once. You can workaround the problem by dragging the files to the blank CD/DVD one by one instead of all at once. This ensures that you get the correct file targeted by each alias. Bug filed under number 4293075.

In case you were wondering, here's the status of the Dashboard bug that I reported two weeks ago: first, engineering contacted me with an e-mail saying they needed more information -- they told me to run "sample Dashboard 15" from the Terminal to give them more information. What was curious about this was that the "Dashboard" part of that command needs to refer to the name of a process, and there is actually no process named "Dashboard" even when it's open. The user interaction of Dashboard is actually handled by the Dock, and the widgets themselves are each handled by a separate instance of the process named "DashboardClient"; so if you have 15 widgets open, you have 15 different instances of DashboardClient running. Therefore, the command "sample Dashboard 15" is a ridiculous suggestion for two reasons: first of all, it fails with an error, and second of all, even if you were to sample a process, you'd need to sample each and every DashboardClient process as well as the Dock process itself in order to track down the problem.

The other problem with this suggestion is that I wouldn't be able to really do this while the bug was manifesting itself, because all user interaction ceases during this time. That means I would have to ssh into my computer from another computer, and run the command remotely (on whatever process was applicable, the Dock or one of the DashboardClient processes).

Since I was a bit bewildered by the suggestion and the fact that doing a sample on the Dock and every widget would be time-consuming, I put off answering the request from Apple engineering. A couple days later they sent me another e-mail saying that this was a known issue, and they closed the bug.

Technological Supernova   Apple Bug Friday   Older   Newer   Post a Comment