Debugging on Mac OS X

This document explains how to debug Mozilla-derived applications such as Firefox, Thunderbird and SeaMonkey on macOS using Xcode. If you want to debug from the terminal see Debugging Mozilla with lldb. For specific information on a way to debug hangs, see Debugging a hang on OS X.

Creating a debuggable build

First you need to build the application you're going to debug using --disable-optimize and --enable-debug-symbols in your .mozconfig (also add --enable-debug if you want assertions etc. compiled in). See the Mac OS X build requirements if you need help creating your own build.

Creating an Xcode project

If you try to create a new Xcode project in an existing directory then Xcode will delete its existing contents (it will warn beforehand). To work around that the steps below have you initialize the project outside the mozilla source tree, close the project, copy the .xcodeproj project "file" into the source tree, and only then reopen the project to finish setting it up.

Note also that since Xcode 7.3.1 it doesn't seem to be possible to have the Xcode project live outside the source tree. If you try to do that then Xcode will simply copy the source files under the project directory rather than link to them (still the case in Xcode 9?) which breaks debugging and the possibility to modify-rebuild-relaunch from inside Xcode.

These steps were last updated for Xode 9:

  1. Open Xcode, and create a new Project with File > New Project. Select the "Cross-platform" tab then under the "Other" template group select the "Empty" project type. the click Next. Name the project and click Next. Select a temporary directory 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. If the source tree hasn't automatically appeared in the left-hand pane in Xcode then right click on the name of your project in that pane, select 'Add files to "<project-name>"', select the contents of your source directory, and click Add.
  4. 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.)
  5. 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 (, etc). The .app file is typically found inside the dist folder in your build directory.
  6. 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".
  7. 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.
  8. 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).
  9. Click "Close" to close the scheme editor.
  10. At this point you can run the application. It should show you source files when you pause or hit breakpoints, but it doesn't automatically pick up your source tree.
  11. 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.

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("")
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.

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.

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

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.

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

For some help on using lldb see Debugging Mozilla with lldb.

Other resources

Apple has an extensive list of debugging tips and techniques.

Questions? Problems?

Try asking in our IRC channels #developers or #macdev.

Document Tags and Contributors

 Last updated by: Jonathan_Watt,