Debugging on Mac OS X

  • Revision slug: Debugging_on_Mac_OS_X
  • Revision title: Debugging on Mac OS X
  • Revision id: 55344
  • Created:
  • Creator: mnoorenberghe
  • Is current revision? No
  • Comment 7 words added

Revision Content

This document explains how to debug Mozilla-derived applications such as Firefox, Thunderbird and SeaMonkey on Mac OS X using Xcode. For specific information on a way to debug hangs, see Debugging a hang on OS X.

Requirements

See the Mac OS X build requirements.

Creating the project in Xcode

Xcode is Apple's set of developer tools and IDE, shipping with the system as of Mac OS X 10.3.

XCode 4

  1. Open Xcode, and create a new workspace using File > New > New Workspace
    Name and save your .xcworkspace file in your source directory
  2. Select File > Add Files to "Workspace" ("Workspace" will appear as your workspace's unique name)
    Choose your source folder and click "Add files"
    Select the "Create groups for any added folders" option.
    This will take a few minutes.
  3. Create a new Project with File > New Project
    Choose command-line application
    Make sure it is a 32-bit (x86) application
    Name it "Firefox"
    You won't actually build this command line app, but you need a project in order to create a Scheme.
  4. Create a new Scheme with Product > New Scheme
    Target: Firefox
    Name: Firefox
  5. Modify the scheme to launch the actual Firefox binary using Product > Edit Scheme
    Under Debug:
    Build Configuration: Debug
    Executable: Choose the path to your debug build (NightlyDebug.app) on disk.
    Debugger: GDB
    Launch: Automatically

    Now you can set breakpoints, in Xcode and choose Product > Run to start Firefox and debug.

XCode 3

  1. Open Xcode, and create a new Project with File > New Project. In the list, choose "Empty Project" as the project type, click Next, name the project and choose where to save the project, then click Finish.
  2. Now you need to add the executable. Select Project > New Custom Executable and type a pretty name, then click the Choose button to locate the .app file that you want to debug (Mozilla.app, Firefox.app, DeerParkDebug.app etc). The .app file is typically found inside the "dist" folder in your build directory. Do not click Finish yet!
  3. Important! - Older versions of Xcode won't make your life that easy; there is still one vital step to be done if you aren't using XCode 3 or higher. You must manually locate the executable binary inside the application bundle, and edit the path to that. In other words, the value of the Executable Path text field should look something like this: " ~/builds/mozilla/dist/DeerParkDebug.app/Contents/MacOS/firefox-bin" (Make sure to select the "-bin" file, the non-"-bin" is just a launch script.)
  4. Now click Finish. An entry with the pretty name you entered in the previous dialog will appear under the "Executables" branch of the "Groups & Files" pane in the Xcode Project window.
  5. In order for Xcode to know what sources you want to debug, you need to tell it where to find them. Go to Project > Edit Active Executable, click the Debugging tab, and finally drag your top-level mozilla/ directory to the panel "Additional folders to find source files in".
  6. Still in "Edit Active Executable", go to the panel titled "Arguments". Add "-P profilename" where profilename is the name of your debugging Firefox profile to the argument list.
  7. Still in "Arguments" panel, add variable "NO_EM_RESTART" with value "1" to the variable list.
  8. Go to Xcode > Preferences. Find the Debugging preferences pane, and make sure "Load symbols lazily" is unchecked.
  9. Finally, if you are debugging Firefox, Thunderbird or some other application that supports multiple profiles, using a separate profile for debugging purposes is recommended. See "Having a profile for debugging purposes" below.

Starting a debug session

When you have created a project file, simply use the menu item Debug > Debug Executable, or change to the debug view by clicking the debug button (typically the third one from the left), and click "Debug".

Setting breakpoints

Setting a breakpoint is easy. Just open the source file you want to debug in Xcode, and click in the margin to the left of the line of code where you want to break.

During the debugging session, each time that line is executed, the debugger will break there, and you will be able to debug it.

Having a profile for debugging purposes

It is recommended to create a separate profile to debug with, whatever your task, so that you don't lose precious data like Bookmarks, saved passwords, etc. So that you're not bothered with the profile manager every time you start to debug, expand the "Executables" branch of the "Groups & Files" list and double click on the Executable you added for Mozilla. Click the plus icon under the "Arguments" list and type "-P <profile name>" (e.g. "-P MozillaDebug"). Close the window when you're done.

Looking at variables

Printing out information in realtime about "native" Objective-C objects is simple. For example, if there's an NSString named 'myString' that you want to get the contents of, you can use the print-object (or short: po) command.

(gdb) po myString
'This is the contents of the string'

Below are instructions for how to deal with C++ objects, such as when debugging code written in XPCOM.

If you've used a debugger before, this is pretty simple. There are two things that should be pointed out, though.

First, when looking at variables that are C++ classes, Xcode separates the protected/private members into their own sub-hierarchy called protected and private, respectively. It will also group inherited member variables into a sub-hierarchy named by the parent class. If you don't see the member variable you're looking for, make sure that you drill down all the way.

If you want to save yourself the hassle of flipping down many little triangles, you can display a variable on the console using

(gdb) p variable_name

Pointer types aren't automatically dereferenced so you may need to do that in the command. It will write out a fully expanded representation to the console. This representation is extremely customizable with various set print feature-name commands. See the gdb doc.

 

See Debugging Mozilla with gdb for non-Mac-specific information about using gdb.

 

Debugging from the Terminal with gdb

Debugging from within Xcode (see above) is much easier, but debugging with gdb in the Terminal is also possible.

1. cd into your Mozilla application (.app) bundle. As an example, we'll use a Firefox debug build.

% cd dist/DeerParkDebug.app/Contents/MacOS 

2. Set the DYLD_LIBRARY_PATH environment variable to tell the loader that this is where all the shared libraries are

% export DYLD_LIBRARY_PATH=`pwd`

3. Debug

% cd ../../.. 
% gdb ./firefox-bin

Questions? Problems?

Try asking nicely in our IRC channel #developers. Often many Mac developers usually hang out in the #camino or #macdev channels.


Original version by Mike Pinkerton (mailto:pinkerton@netscape.com), migrated by Brian Ray (mailto:bray@sent.com). Updated to the new Xcode world and maintained by Håkan Waara (mailto:hwaara@gmail.com).

Revision Source

<p>This document explains how to debug Mozilla-derived applications such as Firefox, Thunderbird and SeaMonkey on Mac OS X using Xcode. For specific information on a way to debug hangs, see <a href="/en/Debugging_a_hang_on_OS_X" title="en/Debugging_a_hang_on_OS_X">Debugging a hang on OS X</a>.</p>
<h3 name="Requirements">Requirements</h3>
<p>See the <a href="/En/Developer_Guide/Build_Instructions/Mac_OS_X_Prerequisites" title="En/Developer_Guide/Build_Instructions/Mac_OS_X_Prerequisites">Mac OS X build requirements</a>.</p>
<h3 name="Creating_the_project_in_Xcode">Creating the project in Xcode</h3>
<p>Xcode is Apple's set of developer tools and IDE, shipping with the system as of Mac OS X 10.3.</p>
<h4>XCode 4</h4>
<ol> <li>Open Xcode, and create a new workspace using File &gt; New &gt; New Workspace<br> Name and save your .xcworkspace file in your source directory</li> <li>Select File &gt; Add Files to "Workspace" ("Workspace" will appear as your workspace's unique name)<br> Choose your source folder and click "Add files"<br> Select the "Create groups for any added folders" option.<br> This will take a few minutes.</li> <li>Create a new Project with File &gt; New Project<br> Choose command-line application<br> Make sure it is a 32-bit (x86) application<br> Name it "Firefox"<br> You won't actually build this command line app, but you need a project in order to create a Scheme.</li> <li>Create a new Scheme with Product &gt; New Scheme<br> Target: Firefox<br> Name: Firefox</li> <li>Modify the scheme to launch the actual Firefox binary using Product &gt; Edit Scheme<br> Under Debug:<br> Build Configuration: Debug<br> Executable: Choose the path to your debug build (NightlyDebug.app) on disk.<br> Debugger: GDB<br> Launch: Automatically<br> <br> Now you can set breakpoints, in Xcode and choose Product &gt; Run to start Firefox and debug.</li>
</ol><h4>XCode 3</h4>
<ol> <li>Open Xcode, and create a new Project with File &gt; New Project. In the list, choose "Empty Project" as the project type, click Next, name the project and choose where to save the project, then click Finish.</li> <li>Now you need to add the executable. Select Project &gt; New Custom Executable and type a pretty name, then click the Choose button to locate the .app file that you want to debug (Mozilla.app, Firefox.app, DeerParkDebug.app etc). The .app file is typically found inside the "dist" folder in your build directory. Do not click Finish yet!</li> <li><strong>Important!</strong> - Older versions of Xcode won't make your life <em>that</em> easy; there is still one vital step to be done if you aren't using XCode 3 or higher. You must manually locate the executable binary inside the application bundle, and edit the path to that. In other words, the value of the Executable Path text field should look something like this: " ~/builds/mozilla/dist/DeerParkDebug.app/Contents/MacOS/firefox-bin" (Make sure to select the "-bin" file, the non-"-bin" is just a launch script.)</li> <li>Now click Finish. An entry with the pretty name you entered in the previous dialog will appear under the "Executables" branch of the "Groups &amp; Files" pane in the Xcode Project window.</li> <li>In order for Xcode to know what sources you want to debug, you need to tell it where to find them. Go to Project &gt; Edit Active Executable, click the Debugging tab, and finally drag your top-level mozilla/ directory to the panel "Additional folders to find source files in".</li> <li>Still in "Edit Active Executable", go to the panel titled "Arguments". Add "-P <var>profilename</var>" where <var>profilename</var> is the name of your debugging Firefox profile to the argument list.</li> <li>Still in "Arguments" panel, add variable "NO_EM_RESTART" with value "1" to the variable list.</li> <li>Go to Xcode &gt; Preferences. Find the Debugging preferences pane, and make sure "Load symbols lazily" is <em>unchecked</em>.</li> <li>Finally, if you are debugging Firefox, Thunderbird or some other application that supports multiple profiles, using a separate profile for debugging purposes is recommended. See "Having a profile for debugging purposes" below.</li>
</ol><h3 name="Starting_a_debug_session">Starting a debug session</h3>
<p>When you have created a project file, simply use the menu item Debug &gt; Debug Executable, or change to the debug view by clicking the debug button (typically the third one from the left), and click "Debug".</p>
<h3 name="Setting_breakpoints">Setting breakpoints</h3>
<p>Setting a breakpoint is easy. Just open the source file you want to debug in Xcode, and click in the margin to the left of the line of code where you want to break.</p>
<p>During the debugging session, each time that line is executed, the debugger will break there, and you will be able to debug it.</p>
<h3 name="Having_a_profile_for_debugging_purposes">Having a profile for debugging purposes</h3>
<p>It is recommended to create a separate profile to debug with, whatever your task, so that you don't lose precious data like Bookmarks, saved passwords, etc. So that you're not bothered with the profile manager every time you start to debug, expand the "Executables" branch of the "Groups &amp; Files" list and double click on the Executable you added for Mozilla. Click the plus icon under the "Arguments" list and type "-P &lt;profile name&gt;" (e.g. "-P MozillaDebug"). Close the window when you're done.</p>
<h3 name="Looking_at_variables">Looking at variables</h3>
<p>Printing out information in realtime about "native" Objective-C objects is simple. For example, if there's an NSString named 'myString' that you want to get the contents of, you can use the print-object (or short: po) command.</p>
<pre class="eval">(gdb) po myString
'This is the contents of the string'
</pre>
<p>Below are instructions for how to deal with C++ objects, such as when debugging code written in XPCOM.</p>
<p>If you've used a debugger before, this is pretty simple. There are two things that should be pointed out, though.</p>
<p>First, when looking at variables that are C++ classes, Xcode separates the protected/private members into their own sub-hierarchy called <strong>protected</strong> and <strong>private</strong>, respectively. It will also group inherited member variables into a sub-hierarchy named by the parent class. If you don't see the member variable you're looking for, make sure that you drill down all the way.</p>
<p>If you want to save yourself the hassle of flipping down many little triangles, you can display a variable on the console using</p>
<pre class="eval">(gdb) p variable_name
</pre>
<p>Pointer types aren't automatically dereferenced so you may need to do that in the command. It will write out a fully expanded representation to the console. This representation is extremely customizable with various <strong>set print feature-name</strong> commands. See the gdb doc.</p>
<p> </p>
<p>See <a class="internal" href="/en/Debugging_Mozilla_with_gdb" title="en/Debugging Mozilla with gdb">Debugging Mozilla with gdb</a> for non-Mac-specific information about using gdb.</p>
<p> </p>
<h3 name="Debugging_from_the_Terminal_with_gdb">Debugging from the Terminal with gdb</h3>
<p>Debugging from within Xcode (see above) is much easier, but debugging with gdb in the Terminal is also possible.</p>
<p>1. cd into your Mozilla application (.app) bundle. As an example, we'll use a Firefox debug build.</p>
<pre class="eval">% cd dist/DeerParkDebug.app/Contents/MacOS 
</pre>
<p>2. Set the DYLD_LIBRARY_PATH environment variable to tell the loader that this is where all the shared libraries are</p>
<pre class="eval">% export DYLD_LIBRARY_PATH=`pwd`
</pre>
<p>3. Debug</p>
<pre class="eval">% cd ../../.. 
% gdb ./firefox-bin
</pre>
<h3 name="Questions.3F_Problems.3F">Questions? Problems?</h3>
<p>Try asking nicely in our IRC channel <a class="link-irc" href="irc://irc.mozilla.org/developers">#developers</a>. Often many Mac developers usually hang out in the <a class="link-irc" href="irc://irc.mozilla.org/camino">#camino</a> or <a class="link-irc" href="irc://irc.mozilla.org/macdev">#macdev</a> channels.</p>
<hr>
<p>Original version by Mike Pinkerton (<a class="link-mailto" href="mailto:pinkerton@netscape.com">mailto:pinkerton@netscape.com</a>), migrated by Brian Ray (<a class="link-mailto" href="mailto:bray@sent.com">mailto:bray@sent.com</a>). Updated to the new Xcode world and maintained by Håkan Waara (<a class="link-mailto" href="mailto:hwaara@gmail.com">mailto:hwaara@gmail.com</a>).</p>
Revert to this revision