Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

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

First you need to build the application you're going to debug, preferably using special options in mozconfig. See the Mac OS X build requirements.

Debugging with XCode 4 and later

Setting up lldb

lldb is the debugger XCode 5+ uses under the hood (previous versions used gdb).

The .lldbinit file in the source tree imports many useful Mozilla specific lldb settings and commands but when debugging in XCode this file is not loaded by default since Xcode does not run using $topsrcdir as its current working directory (see bug 942133).  To work around this add the following to $HOME/.lldbinit and set fallbacktopsrcdir to a Mozilla source directory that you regularly update:

# Import Mozilla settings and utilities (the awkward structure of these
# commands is necessary to avoid double importing of the Mozilla .lldbinit):
script fallbacktopsrcdir = <SET THIS TO A MOZILLA SOURCE DIR>
script istopsrcdir = os.path.exists("mozilla-config.h.in")
script topsrcdir = os.getcwd() if istopsrcdir else fallbacktopsrcdir
script ignored = istopsrcdir or lldb.debugger.HandleCommand("command source -s true " + os.path.join(topsrcdir, ".lldbinit"))

see Debugging Mozilla with lldb for more information.

Note that one important issue that the Mozilla .lldbinit file fixes is that by default some breakpoints will be listed as "pending", and XCode will not stop at them. If you don't include the Mozilla's .lldbinit, you must at least put settings set target.inline-breakpoint-strategy always in your $HOME/.lldbinit as recommended on Debugging Mozilla with lldb.

Creating the project

The upgrade from Xcode 7.3 to 7.3.1 significantly changes the handling of files that are added to a project. Whereas in 7.3 added files could live outside the project directory (or alternatively the project could live outside the mozilla source directory), in 7.3.1 any files that are added that live outside the project directory are copied into the project directory. Previous instructions here had assumed that the Xcode project would be stored outside the mozilla source tree because Xcode would prompt to empty an existing directory if you tried to create a project there. As of 7.3.1 having the project outside the mozilla source tree means that changes to files opened via Xcode don't change the files in the repository though. There are two solutions to this. Either create the Xcode project outside your mozilla source tree and them move it (the *.xcodeproj directory) into your mozilla source tree and only then add files to the project. Otherwise create the Xcode project in an empty directory and then clone a new mercurial repository into that directory.

These steps apply to XCode 4-7:

See the warning note above. We're going to take the approach of assuming that you have an existing source tree that you have built, so we will create the project in an empty directory and them move it into that source tree.

  1. Open Xcode, and create a new Project with File > New Project. In the left hand pane select the "Other" template group, then in the right hand pane select the "Empty" project type. the click Next. Name the project and click Next. Select a temporary to create the project files in and then click Create.
  2. Before going any further, close the project (File > Close Project) and open Finder. Find the *.xcodejproj directroy in the temporary directory, move it into your mozilla source tree, and then double click on it to open it.
  3. In the Product menu, select Scheme > New Scheme and name your scheme (for example, "Debug"). After you click OK, Xcode should open the settings window for the new scheme. (If not, then open its settings from the Product > Edit Scheme menu.)
  4. Select "Run" on the left-hand side of the settings window, then select the "Info" tab. Set the Executable by clicking on "None" and selecting "Other...". A new dialog titled "Choose an executable to launch" will pop up. Browse to the .app file that you want to debug (Firefox.app, NightlyDebug.app etc). The .app file is typically found inside the dist folder in your build directory.
  5. 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. Select the "Arguments" tab in the scheme editor, and click the '+' below the "Arguments passed on launch" field. Add "-P profilename", where profilename is the name of a profile you created previously. Repeat that to also add the argument "-no-remote".
  6. Also in the "Arguments" panel, you may want to add an environment variable MOZ_DEBUG_CHILD_PROCESS set to the value 1 to help with debugging e10s.
  7. Select "Build" from the left of the scheme editor window, and check that there is nothing listed under Targets (otherwise it may cause problems when you try to run the executable for debugging since you will get build errors).
  8. Click OK to close the scheme editor.
  9. At this point you can run the application, and it should show you source files when you pause or hit breakpoints, but it doesn't automatically pick up your source tree.
  10. In order for Xcode to know what sources you want to debug, you need to tell it where to find them. In the File menu choose 'Add Files to "your-project"'. Browse to your source tree and either command-click the set of directories you care about, or just select the whole tree. Xcode will import everything, including .hg directories, so you will need to remove them from your project after the import. The amount of work to carefully select which source files to import doesn't seem to be much different than the effort to clean up after importing everything.

Starting a debug session

Make sure breakpoints are active (which implies running under the debugger) by opening the Product menu and selecting "Debug / Activate Breakpoints" (also shown by the "Breakpoints" button in the top right section of the main window). Then click the "Run" button or select "Run" from the Product menu.

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.

Note that with the default configuration, some breakpoints will be listed as "pending", and XCode will not stop at them. If you don't include the Mozilla's .lldbinit, you must at least put settings set target.inline-breakpoint-strategy always in your $HOME/.lldbinit as recommended on Debugging Mozilla with lldb.

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.

Using Mozilla-specific lldb commands

If you included the .lldbinit when Setting up lldb, you can use Mozilla-specific lldb commands in the console, located in the Debug area of XCode. For example, type js to see the JavaScript stack. For more information, see Debugging Mozilla with lldb.

Looking at variables

Note: XCode 5+ uses lldb instead of gdb, so parts of this section might need to be updated.

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 documentation.

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

Debugging e10s child processes

Using XCode to debug child processes created by an e10s-enabled browser is a little trickier than debugging a single-process browser, but it can be done. These directions were written using XCode 6.3.1

  1. Complete all the steps above under "Creating the Project"
  2. From the "Product" menu, ensure the scheme you created is selected under "Scheme", then choose "Scheme > Edit Scheme"
  3. In the resulting popup, click "Duplicate Scheme"
  4. Give the resulting scheme a more descriptive name than "Copy of Scheme"
  5. Select "Run" on the left-hand side of the settings window, then select the "Info" tab. Set the Executable by clicking on the "Executable" dropdown, and selecting the plugin-container.app that is inside the app bundle of the copy of Firefox you want to debug.
  6. On the same tab, under "Launch" select "Wait for executable to be launched"
  7. On the "Arguments" tab, remove all arguments passed on launch.

Now you're ready to start debugging:

  1. From the "Product" menu, ensure the scheme you created above is selected under "Scheme"
  2. Click the "Run" button. The information area at the top of the window will show "Waiting for plugin-container to launch"
  3. From a command line, run your build of Firefox. When that launches a child process (for example, when you start to load a webpage), XCode will notice and attach to that child process. You can then debug the child process like you would any other process.
  4. When you are done debugging, click the "Stop" button and quit the instance of Firefox that you were debugging in the normal way.

Debugging from the Terminal

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

With lldb

See Debugging Mozilla with lldb

With gdb

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

Other resources

Apple has an extensive list of debugging tips and techniques.

Questions? Problems?

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

Creating the project in Xcode 3 and earlier

  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. Go to Xcode > Preferences. Find the Debugging preferences pane, and make sure "Load symbols lazily" is unchecked.
  8. 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 debugging 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".


Original version by Mike Pinkerton (mailto:[email protected]), migrated by Brian Ray (mailto:[email protected]). Updated to the new Xcode world and maintained by Håkan Waara (mailto:[email protected]).

Document Tags and Contributors

 Last updated by: Jonathan_Watt,