Posts Tagged debugging
Beta Testing iPhone Applications
Posted by Sébastien Stormacq in Apple, iPhone, Oracle, Personal on 08/06/2011
| I am about to release another iPhone application allowing users to visually manage voice mail messages left on their enterprise messaging solution, based on Oracle Beehive Collaboration and Communication Suite.
This application is similar to Apple’s Visual Voice Messaging application that is deployed for some carriers. Testing an iPhone application before it is deployed through the App Store might be tricky and is reserved for users having a minimal technical knowledge. This article describes the steps required to join a testing program and to collect logs and debugging information to be reported to the developer. Before installing an application on your iPhone, it has to be digitally signed by the developer and by Apple (when distributed on the App Store). For ad-hoc distribution, i.e., without going through the App Store, the application will be signed specifically for your device. The developer needs to know your Device ID (UDID). |
 |
Step #1 – collect your UDID and send it to the developer
First step for beta testing an iPhone application is to collect your UDID and send it to the developer.
To do this, connect your device to your Mac/Windows and launch iTunes. In iTunes, select your device in the ‘Devices’ section and navigate to the Summary tab. Click on the Serial Number label to reveal the Identifier field and the 40 character UDID. Press Command+C (CTRL-C on Windows) to copy the UDID to your clipboard. Then paste it (Command+V or CTRL-V) in a mail message.
Step #2 – Install application
Once the developer knows your UDID, he will generate an application’s release authorized to run on your device. Most of the time, you will receive the application as a ZIP file through email or web site download.
- Unzip the file you received
- Drag’n drop the application in iTunes
- Sync your device with iTunes to install the application
You should then see the application icon on your device.
Step #3 – Provide feedback and collect log files for crashes
We are interested to collect all kind of feedbacks and testing conditions
- General application usage, ergonomy, performance etc … many of these are subjectives but all suggestions will be considered. Sometimes suggestions will be integrated immediately, sometimes they will be planned for a future release.
- Different devices – you’re mostly welcome to test on older iPhone, iPod Touch or even iPad.
- Slow / poor network connection. Real life network conditions are difficult to test on a development machine, only real life usage, on the street, in a cab, in an airport etc …
If the application crashes or if you think you’ve find a bug, please report it as precisely as possible, in particular, I would like to know
- what version you are using ? (version number is provided in the mail with the application)
- what device you are using ?
- what are the precise steps to reproduce ?
- is it always reproducible or not ?
The application generate a log file that contains a precise description of what happens within the application. Here are the steps to collect and send me log files.
- Download Apple’s iPhone Configuration Utility (Mac and Windows)
- With your device connected, run the iPhone Configuration Utility
- Click your connected device
- Go to the Console tab (see screenshot below)
- Clear the log (button at the bottom to the left)
- Try to install and/or launch the application and reproduce the error
- Select the relevant log lines (or just everything)
- Click the Save Console As… button and save the file
- E-mail the file to me
That’s all for now. Thank you for your valuable feedback !
How to remotely capture a core dump on a Mac ?
Posted by Sébastien Stormacq in Mac OS X on 21/06/2010
Mac OS X is usually a very stable OS, over the last 10 years I can count on my fingers the rare number of cases when the system entirely crashed and required a reboot.
(I am not counting the deliberate attempts to make it crash , playing with development version of kernel modules or very very early builds of all kinds)
Since a couple of months however, I am able to crash the entire system just using iTunes.
When downloading multiple files simultaneously or when starting any type of concurrent disk access for several minutes, iTunes freezes, bringing the whole system down with him.
It looks like this is linked to my type of machine (iMac 24″) as I can not reproduce on any other three machines at home. I am not the only one experiencing this issue. Apple’s support forums host a thread here and another here with people describing exact similar symptoms (some of them with PowerMacs too)
As I am part of the Apple developer Program, I opened a bug report to request attention about this.
Surprisingly, Apple answered with 2-3 weeks asking for more details, in particular, a stack trace of the system while in frozen state.
Stackshot can be enabled as follows:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.stackshot.plist
Then, type the following chord:
Control-Option-Command-Shift-Period
a file will be written out /Library/Logs/stackshot.log and a symbolized file will be written to /Library/Logs/stackshot-syms.log
Unfortunately, this does not help in my case as the whole system was unresponsive when the crash occurs, I have no possibility to type any command while the system is frozen.
Apple then asked me to produce a core dump, using Non Maskable Interrupt trigger and a remote core dump server.
Basically, the idea is to configure the kernel to let it send a core dump to a remote server, through the network. On another machine, you’ll have to setup the core dump server, i.e. a process that will listen on the network, will accept the connection from the crashed kernel and will dump the data to a file on disk.
Once the kernel client and the core dump server configured, you need to tell the kernel to generate the data and send them to the remote server. For this top happen, you’ll need to force a panic with DTrace for example.
But in my case, the kernel is not panicking, just freezing.
I had to generate a Non Maskable Interrupt to activate the debugging process. Once properly configured as described in Apple Technical Note, this is a simple as shortly pressing the POWER button.
This method is explained with many details and options in Apple technical Note TN2118. It is surprisingly easy to setup and allows to collect valuable debugging information for developers. I am attaching a screen shot of the crashed machine while in this state.
I hope Apple will be able to provide a fix for this issue.