Debugging a hang on OS X

  • Revision slug: Debugging_a_hang_on_OS_X
  • Revision title: Debugging a hang on OS X
  • Revision id: 172090
  • Created:
  • Creator: Sardisson
  • Is current revision? Yes
  • Comment add the old export instructions to the 10.4 section, remove redundant headers

Revision Content

If you find a hang in an application, it is very useful for the developer to know where in the code this hang happens, especially if he or she can't reproduce it. Below are steps you can use to attach so-called "Samples" to bug reports.

Creating the sample on Mac OS X 10.5

  1. When the application is still hung, open up Spin Control.app (it’s in your <tt>/Developer/Applications/Performance Tools/</tt> folder; if it is missing, install the latest Computer Hardware Understanding Development (CHUD) Tools from Apple).
  2. By default, sampling of any hanging application will begin automatically.
  3. After about 3-4 seconds, select the hanging application in the “Detected Hangs” window and click the “Interrupt Sampling” button.
    Note that sampling will quickly hog up a lot of memory if you leave it on for too long!
  4. When it's done parsing the data, click the "Show text report" button; a new window will open with a couple of rows with stacktraces for all the threads in the sampled application.
  5. If you need to upload the sample to Bugzilla, select all the sample text, copy it into your favorite text editor, and save as a plain-text file.
  6. For a more detailed view of the sample data, make sure the sample you just recorded is selected in the “Detected Hangs” window and click on the “Open…” button.

Creating the sample on Mac OS X 10.4

  1. When the application is still hung, open up Sampler.app (it’s in your <tt>/Developer/Applications/Performance Tools/</tt> folder; if it is missing, install the latest Computer Hardware Understanding Development (CHUD) Tools from Apple.).
  2. Choose File > Attach...
  3. Select "firefox-bin" or the hung application you want a sample from.
  4. Now, click "Start recording". Note that only 3-4 seconds usually suffice, note that this will quickly hog up a lot of memory if you leave it on for too long!
  5. When it's done parsing the data, you should now have a couple of rows with stacktraces for all the threads in the sampled application.
  6. When you have the raw Sample data, you can't just save that and attach it to a bug, because the format is not very usable (unless the developer is a Mac hacker). Export it using Tools > Generate Report, and attach this as a text file to the bug report.

The final data will show where the application spent all its time when it was hung, and hopefully your bug will be easier to fix now!

See also

Debugging on Mac OS X

Revision Source

<p>If you find a hang in an application, it is very useful for the developer to know where in the code this hang happens, especially if he or she can't reproduce it. Below are steps you can use to attach so-called "Samples" to bug reports.
</p>
<h3 id="Creating_the_sample_on_Mac_OS_X_10.5" name="Creating_the_sample_on_Mac_OS_X_10.5">Creating the sample on Mac OS X 10.5</h3>
<ol><li> When the application is still hung, open up Spin Control.app (it’s in your <tt>/Developer/Applications/Performance Tools/</tt> folder; if it is missing, install the latest <a class="external" href="http://developer.apple.com/tools/download/">Computer Hardware Understanding Development (CHUD) Tools</a> from Apple).
</li><li> By default, sampling of any hanging application will begin automatically.
</li><li> After about 3-4 seconds, select the hanging application in the “Detected Hangs” window and click the “Interrupt Sampling” button.
<dl><dd> Note that sampling <b>will quickly hog up a lot of memory</b> if you leave it on for too long!
</dd></dl>
</li><li> When it's done parsing the data, click the "Show text report" button; a new window will open with a couple of rows with stacktraces for all the threads in the sampled application.
</li><li> If you need to upload the sample to Bugzilla, select all the sample text, copy it into your favorite text editor, and save as a plain-text file.
</li><li> For a more detailed view of the sample data, make sure the sample you just recorded is selected in the “Detected Hangs” window and click on the “Open…” button.
</li></ol>
<h3 id="Creating_the_sample_on_Mac_OS_X_10.4" name="Creating_the_sample_on_Mac_OS_X_10.4">Creating the sample on Mac OS X 10.4</h3>
<ol><li> When the application is still hung, open up Sampler.app (it’s in your <tt>/Developer/Applications/Performance Tools/</tt> folder; if it is missing, install the latest <a class="external" href="http://developer.apple.com/tools/download/">Computer Hardware Understanding Development (CHUD) Tools</a> from Apple.).
</li><li> Choose File &gt; Attach...
</li><li> Select "firefox-bin" or the hung application you want a sample from.
</li><li> Now, click "Start recording". Note that only 3-4 seconds usually suffice, note that <b>this will quickly hog up a lot of memory</b> if you leave it on for too long!
</li><li> When it's done parsing the data, you should now have a couple of rows with stacktraces for all the threads in the sampled application.
</li><li> When you have the raw Sample data, you can't just save that and attach it to a bug, because the format is not very usable (unless the developer is a Mac hacker). Export it using Tools &gt; Generate Report, and attach this as a text file to the bug report.
</li></ol>
<p>The final data will show where the application spent all its time when it was hung, and hopefully your bug will be easier to fix now!
</p>
<h3 id="See_also" name="See_also"> See also </h3>
<p><a href="en/Debugging_on_Mac_OS_X">Debugging on Mac OS X</a>
</p>
Revert to this revision