Apple keeps working on making Xcode more stable all the time. While Xcode 4.6 has much improved in terms of simply quitting on you, people report that more often now they see Xcode just hang.
One method to deal with race conditions in a highly parallelized application like Xcode is to add semaphores and locking. Unfortunately locking is not the end-all of all all Xcode problems, even with a liberal sprinkling. A blocked main thread is a blocked main thread.
Here is what you should do next time you encounter the beach ball of doom.
Several Apple employees have commented on Twitter that the most helpful thing you can do next time you see Xcode misbehaving is…
Sampling the Xcode App
There are two methods for sampling the current application state: one for terminal geeks and one for keyboard artists.
In terminal you can type this to sample the named app:
sudo sysdiagnose Xcode |
This tool tells you what it does quite in detail:
This diagnostic tool generates files that allow Apple to investigate issues with your computer and help Apple to improve its products. The generated files may contain some of your personal information, which may include, but not be limited to, the serial number or similar unique number for your device, your user name, or your computer name. The information is used by Apple in accordance with its privacy policy (www.apple.com/privacy) and is not shared with any third party. By enabling this diagnostic tool and sending a copy of the generated files to Apple, you are consenting to Apple’s use of the content of such files.
This tool does a plethora of stuff, all related to the process that matches the name you passed in as parameter.
The results of the sampling are aggregated in /var/tmp and compressed into a tar.gz archive of 45 MB in my case, 615 MB uncompressed. Ah, how wonderfully compressible text files are…
This archive contains a crashes_and_spins folder which a couple of files with the fitting extention “hang”. Inspect one and you will see sort of a big call stack. This is what can tell Apple engineers what is causing the holdup. If you are daring enough to inspect on of these files you will see tons of psych_mutexwait, semaphore_wait_trap, __spin_lock, OSSpinLockLock and other sorts of lines that express some sort of lock waiting.
Just like Neo who can see Matrix, Apple’s Xcode engineers are able to tell the exact line of code for each beachball just from looking at these spin dumps. Yes, they are that good.
The second method to prefer if you prefer a keyboard shortcut to being a terminal jockey is this: Shift+Ctrl+Alt+Cmd+Period – we shall henceforth call…
The Spinball Grip
Some people call the Alt key the “Option” key. Nevertheless this combination should work on any keyboard layout.
Please don’t make fun of me for programming on a German-layout keyboard… rather use the time to send your collected data to Apple.
Conclusion
Of course we hope for as little spin locks and crashes as possible, but we all know that Software is never “done”. It is our duty as iOS and Mac developers to help Apple improve Xcode’s stability by providing as much pertinent data as possible.
Next time your Xcode beachballs, file a Radar and attach the report you now know how to generate. This way, if the next Xcode version has less hangs, you can proudly claim “See, Apple implemented a suggestion of mine!” (to crash/hang less)
PS: An Apple engineer would like me to mention that they do generally prefer the command line version since it adds a specific focus to the mentioned process.
Categories: Recipes
Or next time, use AppCode.
“Yes, they are that good.”
Then why is XCode a steaming pile of poo?