Bug 1658505 - updated links and updated some code blocks. r=sylvestre

Minidumps are not available to everyone. For details on how to gain

access and where to find minidump files for crash reports, consult the

`crash report

documentation </en-US/docs/Understanding_crash_reports>`__.

:ref:`crash report documentation <Understanding Crash Reports>`

Using the MS Visual Studio debugger

-----------------------------------

#. Set up the debugger to `use the Mozilla symbol

   server </en/Using_the_Mozilla_symbol_server>`__ and `source

   server </en-US/docs/Mozilla/Using_the_Mozilla_source_server>`__\ `. </en/Using_the_Mozilla_symbol_server>`__

   server <https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server>`__ and `source

   server <https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_source_server>`__\.

#. Double-click on the minidump file to open it in the debugger.

#. When it loads, click the green icon in the visual studio debugger

   toolbar that looks like a play button.

.. note::

For Firefox releases older than Firefox 41, you will also need to

install the relevant release of Firefox (for example from

`here <https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/>`__),

path to a Linux minidump will generate a core file on stdout which can

then be loaded in gdb as usual. You will need to manually download the

matching Firefox binaries, but then you can use the `GDB Python

script </en/Using_the_Mozilla_symbol_server#Downloading_symbols_on_Linux_Mac_OS_X>`__

script <https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server#Downloading_symbols_on_Linux_Mac_OS_X>`__

to download symbols.

.. note::

The ``minidump-2-core`` source does not currently handle processing

minidumps from a different CPU architecture than the system it was

built for. If you want to use it on an ARM dump, for example, you may

   `minidump_stackwalk <https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide>`__

   breakpad tool to get the stack trace.

.. code:: brush:

.. code:: bash

   Example:

Use GDB 5, or higher. A more recent version of GDB can be obtained from

`sourceware <https://sourceware.org/gdb/>`__ or your Linux distro repo.

If you are running less than 256 MB of RAM, be sure to see `Using gdb on

wimpy computers </en/Using_gdb_on_wimpy_computers>`__.

wimpy computers <https://developer.mozilla.org/en/Using_gdb_on_wimpy_computers>`__.

Where can I find general gdb documentation?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The preferred method, is using the

`mach </en-US/docs/Developer_Guide/mach>`__ command-line tool to run the

`mach <https://developer.mozilla.org/en-US/docs/Developer_Guide/mach>`__ command-line tool to run the

debugger, which can bypass several optional defaults. Use "mach help

run" to get more details. If inside the source directory, you would use

"./mach". If you have previously `added mach to your

path </en-US/docs/Developer_Guide/mach#Adding_mach_to_your_shell's_search_path>`__,

path <https://developer.mozilla.org/en-US/docs/Developer_Guide/mach#Adding_mach_to_your_shell's_search_path>`__,

then just use "mach". Please note that `mach is aware of

mozconfigs </en-US/docs/Developer_Guide/mach#mach_and_mozconfigs>`__.

mozconfigs <https://developer.mozilla.org/en-US/docs/Developer_Guide/mach#mach_and_mozconfigs>`__.

.. code:: eval

.. code:: bash

   $ ./mach run --debug [arguments to pass to firefox]

splitting rules. For example, if you wanted to run the command 'show

args' when gdb starts, you would use:

.. code:: eval

.. code:: bash

   $ ./mach run --debug --debugger-args "-ex 'show args'"

generating synthetic segfaults to support the slower script dialoging

mechanism.

.. code:: eval

.. code::

   $ gdb OBJDIR/dist/bin/firefox

See this `old

version </index.php?title=en/Debugging_Mozilla_with_gdb&revision=43>`__

for specialized instructions on older builds of Firefox.

   (gdb) OBJDIR/dist/bin/firefox

How do I pass arguments in prun?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Set the arguments in GDB before calling prun. Here's an example on how

to do that:

.. code:: eval

.. code::

   (gdb) set args https://www.mozilla.org

   (gdb) prun

How do I set a breakpoint when a component is loaded? 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. note::

In Firefox Version 57 (and possibly earlier) XPCOM_BREAK_ON_LOAD does

not seem to exist.

or ``necko`` is loaded, you set the variable to ``raptor:necko``. Here's

an example:

.. code:: eval

.. code::

   (gdb) set env XPCOM_BREAK_ON_LOAD raptor:necko

   (gdb) prun

``InitCOMGlue()``, you should be able to set breakpoints on many more

symbols, source files, and continue running.

::

.. code::

   (gdb) break main

   (gdb) run

One suggestion is this:

.. code:: eval

.. code::

   (gdb) print ((PRUnichar*)uri.mBuffer)[0]@16

   $47 = {114, 100, 102, 58, 110, 117, 108, 108, 0, 0, 8, 0, 0, 0, 37432,

.. code:: eval

.. code::

   (gdb) print aURI

   $1 = (const PRUnichar *) 0x855e6e0

-  Define helper functions in your .gdbinit

.. code:: brush:

.. code::

   # Define a "pu" command to display PRUnichar * strings (100 chars max)

   # Also allows an optional argument for how many chars to print as long as

little memory but it shouldn't hurt anything if you only do it a few

times in one gdb session. (via akkana@netscape.com)

.. code:: eval

.. code::

   (gdb) p string.ToNewCString()

Another method (via bent) is the following (replace ``n`` with: the

returned length of your string):

::

.. code::

   (gdb) p string.Length()

   $1 = n

XPCOM interface pointer, by looking at the mangled name of the symbol

for the object's vtable:

.. code:: eval

.. code::

   (gdb) p aKidFrame

   $1 = (nsIFrame *) 0x85058d4

If you have JavaScript Engine code on the stack, you'll probably want a

JS stack in addition to the C++ stack.

::

.. code::

   (gdb) call DumpJSStack() 

See `https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_JavaScript </en-US/docs/Mozilla/Debugging/Debugging_JavaScript>`__

See `https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_JavaScript <https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_JavaScript>`__

for more JS debugging tricks.

How can I debug race conditions and/or how can I make something different happen at NS_ASSERTION time?

debugger, or defining a preferred setup and running any commands you

wish. For example:

.. code:: eval

.. code:: bash

   $ ./run-mozilla.sh /bin/bash

   MOZILLA_FIVE_HOME=/home/USER/src/mozilla/build/dist/bin

Running mozilla-bin inside GDB fails with an error message like:

.. code:: eval

.. code::

   Starting program:

   /u/dmose/s/mozilla/mozilla-all/mozilla/dist/bin/./mozilla-bin

``PR_ASSERT()`` and ``NS_ASSERTION()``. To see where it's asserting you

can stop at two places:

.. code:: eval

.. code::

   (gdb) b abort

   (gdb) b exit

management tools. The best way is install the ``yum-utils`` package, and

then use the ``debuginfo-install`` command to install all the debuginfo:

::

.. code:: bash

   # yum install yum-utils

   # debuginfo-install firefox 

   $ yum install yum-utils

   $ debuginfo-install firefox

This can be done manually using:

.. code:: eval

.. code:: bash

    # yum install GConf2-debuginfo ORBit2-debuginfo atk-debuginfo \

    $ yum install GConf2-debuginfo ORBit2-debuginfo atk-debuginfo \

    cairo-debuginfo dbus-debuginfo dbus-glib-debuginfo expat-debuginfo \

    fontconfig-debuginfo freetype-debuginfo gcc-debuginfo glib2-debuginfo \

    glibc-debuginfo gnome-vfs2-debuginfo gtk2-debuginfo gtk2-engines-debuginfo \

    libXrender-debuginfo libbonobo-debuginfo libgnome-debuginfo \

    libselinux-debuginfo pango-debuginfo popt-debuginfo scim-bridge-debuginfo

Ubuntu 8.04

^^^^^^^^^^^

Ubuntu provides similar debug symbol packages for many of its libraries,

though not all of them. To install them, run:

.. code:: eval

    $ sudo apt-get install libatk1.0-dbg libc6-dbg libcairo2-dbg \

    libfontconfig1-dbg libgcc1-dbg libglib2.0-0-dbg libgnomeui-0-dbg \

    libgnomevfs2-0-dbg libgnutls13-dbg libgtk2.0-0-dbg libice6-dbg \

    libjpeg62-dbg libpango1.0-0-dbg libpixman-1-0-dbg libstdc++6-4.2-dbg \

    libx11-6-dbg libx11-xcb1-dbg libxcb1-dbg libxft2-dbg zlib1g-dbg

Debugging electrolysis (e10s)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To get the child process id use:

::

.. code::

   MOZ_DEBUG_CHILD_PROCESS=1 mach run

See also

~~~~~~~~~

-  `Debugging </En/Debugging>`__

-  `Debugging <https://developer.mozilla.org/En/Debugging>`__

-  `Performance tools <https://wiki.mozilla.org/Performance:Tools>`__

-  `Fun with

   gdb <https://blog.mozilla.com/sfink/2011/02/22/fun-with-gdb/>`__ by

The in-tree ``.lldbinit`` should be loaded automatically in most cases

when running lldb from the command line (e.g. using

```mach`` </en-US/docs/Mozilla/Developer_guide/mach>`__), but **not**

```mach`` <https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/mach>`__), but **not**

when using XCode. See `Debugging on Mac OS

X </en-US/docs/Debugging_on_Mac_OS_X>`__ for information on setting up

X <https://developer.mozilla.org/en-US/docs/Debugging_on_Mac_OS_X>`__ for information on setting up

XCode.

.. warning::

   lldb will not stop at them). To fix this add the following to your

   $HOME/.lldbinit file:

   .. code:: eval

   .. code::

      # Mozilla's use of UNIFIED_SOURCES to include multiple source files into a

      # single compiled file breaks lldb breakpoint setting. This works around that.

You can attach to Firefox with following command:

.. code:: eval

.. code::

   (lldb) process attach --name firefox

To start Firefox under the debugger, run ``lldb`` followed by "--",

followed by the command line you'd like to run, like this:

::

.. code:: bash

   $ lldb -- obj-ff-dbg/dist/Nightly.app/Contents/MacOS/firefox-bin -no-remote -profile /path/to/profile

Then set breakpoints you need and start the process:

::

.. code::

   (lldb) breakpoint set --name nsInProcessTabChildGlobal::InitTabChildGlobal

   Breakpoint created: 1: name = 'nsInProcessTabChildGlobal::InitTabChildGlobal', locations = 0 (pending)

On Linux, run Valgrind with the following options.

::

.. code::

   --smc-check=all-non-file --vex-iropt-register-updates=allregs-at-mem-access --show-mismatched-frees=no --read-inline-info=yes

Also, run with the following environment variable set.

::

.. code::

   G_SLICE=always-malloc

On Mac, run Valgrind with the following options.

::

.. code::

   --smc-check=all-non-file --vex-iropt-register-updates=allregs-at-mem-access --show-mismatched-frees=no --dsymutil=yes

To run a mochitest under Valgrind, use the following command.

::

.. code:: bash

   ./mach mochitest-plain --debugger="valgrind" --debugger-args="$VALGRIND_OPTIONS" relative/path/to/tests

   $ ./mach mochitest-plain --debugger="valgrind" --debugger-args="$VALGRIND_OPTIONS" relative/path/to/tests

Where ``$VALGRIND_OPTIONS`` are the options described

`above </en-US/docs/Mozilla/Testing/Valgrind#Run>`__. You might also

:ref:`above <Debugging Firefox With Valgrind>`. You might also

need ``--trace-children=yes`` to trace into child processes.

As of December 2014 it is possible to do a complete run of

VS2010 instead.

Follow the steps in `Windows Build

Prerequisites </En/Developer_Guide/Build_Instructions/Windows_Prerequisites>`__

Prerequisites <https://developer.mozilla.org/En/Developer_Guide/Build_Instructions/Windows_Prerequisites>`__

to get a working build setup on the Host.

Install VMWare Workstation 7 for Windows 32-bit and 64-bit, Main

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Because nightly builds have debug information available from the Mozilla

`symbol server </en/Using_the_Mozilla_symbol_server>`__, it is

`symbol server <https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server>`__, it is

relatively easy to use them for record and replay debugging.

-  Create a shared directory which is available on both the host and