MEFTGG: MacOSX crashes

This page is maintained by James Wookey ( ).

This page documents various crashes encountered and how to avoid them.

This information is provided in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any views represented here are entirely personal; they do not reflect the views of the School of Earth Sciences, or the University of Bristol.

Installing Leopard results in the Blue Screen of Death

This caused a storm of problems and protests when Leopard was first released.
• This may be due to an infamous problem with a legacy version of the Unsanity APE Framework. You may have this without realising, for example if you have an old version of the Logitech Control Centre (<2.4). This Apple Technote gives more information, and recovery methods. Personally, I used the command line method, which was quick and painless.

Loginwindow.app crashes after Software Update. (Intel only, so far as I know).

This is the most serious (repeatable) crash that I have yet encountered on Mac OS X. It has critical symptoms and can be real headache to recover.

• Symptoms:
  The crash occurs when applying a Software Update (usually those which require a restart), after rebooting the machine. The Login Window appears as normal (if automatic login is disabled), but after username and password are entered the GUI crashes out to a black BSD-style command line login. It is possible to login to this, but generally after a few seconds this generally becomes a blank blue screen where no interaction is possible. It is still possible to SSH into the machine, however.

  Investigation of the various log files in /Library/Logs/CrashReport has shown that the crash occurs in the SecurityAgent, originating in a dynamic library libstdc++.6.dylib

• Avoidance:
  My preliminary conclusion is that the cause of this crash is a collision between versions of the GCC. It has (to my knowledge) only been observed in machines which have a version of GCC installed in /usr/local. Avoiding the occurrence of the bug appears therefore relatively simple:

  • Before running a software update, simply rename your /usr/local directory; for example, sudo mv /usr/local /usr/local.hold.

  • Then, run the update as normal and restart as required. Repeat until no updates remain.
  • Move or merge your /usr/local.hold back into /usr/local (you might want to check whether the Software Update has created its own /usr/local).

  Like I say, these conclusions are preliminary (and have only been tested on a couple of machines), if you have experienced this crash on a machine without a version of GCC installed in /usr/local, I would very much like to hear about. ()

• Recovery:
  Unfortunately there is no very simple fix for this bug, which is a shame since you may have only found this page when searching for remedies after the fact. The only way I have found to repair the damage is by running an Archive and Install from the original Tiger DVD. This preserves most settings and data, but you will have to reinstall things like the Xcode tools. /usr/local will also be wiped out, but this can be recovered from the /Previous Systems/ folder. Before re-installing anything however, you should run all the necessary Software Updates (so you don't have to do it twice!).

  If anyone has a method of recovering this error which doesn't involve Archive and Install, please do let me know (). It could possibly be done by re-applying the update (for example, using a combo-updater), but I can't figure out a way of doing this on the command line (which is all you have after this crash).