mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-25 05:41:12 +00:00
Bug 1658505 - fix codespell and rst errors and remove unused reference. r=sylvestre
Differential Revision: https://phabricator.services.mozilla.com/D86810
This commit is contained in:
Emil Farisan
parent
8d75cc29fb
commit
bfa8dd8228
@ -17,8 +17,6 @@ Windows debugging tools. Each minidump includes the following data.
|
||||
- (Optional) Other memory regions, if requested by the application.
|
||||
- (Optional) Other platform-specific data.
|
||||
|
||||
.. _Accessing_minidumps_from_crash_reports:
|
||||
|
||||
Accessing minidumps from crash reports
|
||||
--------------------------------------
|
||||
|
||||
@ -27,8 +25,6 @@ access and where to find minidump files for crash reports, consult the
|
||||
`crash report
|
||||
documentation </en-US/docs/Understanding_crash_reports>`__.
|
||||
|
||||
.. _Using_the_MS_Visual_Studio_debugger:
|
||||
|
||||
Using the MS Visual Studio debugger
|
||||
-----------------------------------
|
||||
|
||||
@ -67,7 +63,7 @@ Then you'll be able to examine:
|
||||
the stack trace
|
||||
The debugger shows the stack trace. You can right-click on any frame
|
||||
in the stack, and then choose "go to disassembly" or "go to source".
|
||||
(Choosing "go to dissassembly" from the source view might not get you
|
||||
(Choosing "go to disassembly" from the source view might not get you
|
||||
to the right place due to optimizations.) When looking at the
|
||||
source, beware that the debugging information will associate all
|
||||
inlined functions as part of the line into which they were inlined,
|
||||
@ -104,8 +100,6 @@ local variables
|
||||
Studio can't figure something out from the minidump, it might show
|
||||
you 00000000 (is this true?).
|
||||
|
||||
.. _Using_minidump-2-core_on_Linux:
|
||||
|
||||
Using minidump-2-core on Linux
|
||||
------------------------------
|
||||
|
||||
@ -129,8 +123,6 @@ to download symbols.
|
||||
built for. If you want to use it on an ARM dump, for example, you may
|
||||
need to build the tool for ARM and run it under QEMU.
|
||||
|
||||
.. _Using_other_tools_to_inspect_minidump_data:
|
||||
|
||||
Using other tools to inspect minidump data
|
||||
------------------------------------------
|
||||
|
||||
@ -174,13 +166,11 @@ checkout, and that you have built Breakpad in an objdir named
|
||||
module, and a -d option to print relative paths to the symbol files
|
||||
that would be used instead of the module filenames.
|
||||
|
||||
.. _Getting_a_stack_trace_from_a_crashed_B2G_process:
|
||||
|
||||
Getting a stack trace from a crashed B2G process
|
||||
------------------------------------------------
|
||||
|
||||
#. Get the minidump file in the phone at
|
||||
/data/b2g/mozilla/*.default/minidump/. You can use `adb
|
||||
/data/b2g/mozilla/\*.default/minidump/. You can use `adb
|
||||
pull <http://developer.android.com/tools/help/adb.html>`__ for that.
|
||||
#. Build the debug symbols using the command ./build.sh buildsymbols
|
||||
inside the B2G tree. The symbol files will be generated in
|
||||
|
||||
@ -9,8 +9,6 @@ Use GDB 5, or higher. A more recent version of GDB can be obtained from
|
||||
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>`__.
|
||||
|
||||
.. _Where_can_I_find_general_gdb_documentation:
|
||||
|
||||
Where can I find general gdb documentation?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -22,8 +20,6 @@ can use a graphical front-end to GDB like
|
||||
`insight <https://sourceware.org/insight/>`__. For more information see
|
||||
https://sourceware.org/gdb/current/onlinedocs/gdb/
|
||||
|
||||
.. _How_do_I_debug_Mozilla_on_Linux.3F:
|
||||
|
||||
How do I run Firefox under gdb?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -63,8 +59,6 @@ See this `old
|
||||
version </index.php?title=en/Debugging_Mozilla_with_gdb&revision=43>`__
|
||||
for specialized instructions on older builds of Firefox.
|
||||
|
||||
.. _How_do_I_pass_arguments_in_prun.3F:
|
||||
|
||||
How do I pass arguments in prun?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -76,8 +70,6 @@ to do that:
|
||||
(gdb) set args https://www.mozilla.org
|
||||
(gdb) prun
|
||||
|
||||
.. _How_do_I_set_a_breakpoint_in_a_library_that_hasn.27t_been_loaded.3F:
|
||||
|
||||
How do I set a breakpoint in a library that hasn't been loaded?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -95,8 +87,6 @@ you have to set a breakpoint you can set a breakpoint in ``_dl_open``.
|
||||
This function is called when a new library is loaded, when you can
|
||||
finally set your breakpoint.
|
||||
|
||||
.. _How_do_I_set_a_breakpoint_when_a_component_is_loaded.3F:
|
||||
|
||||
How do I set a breakpoint when a component is loaded?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -118,8 +108,6 @@ an example:
|
||||
(gdb) set env XPCOM_BREAK_ON_LOAD raptor:necko
|
||||
(gdb) prun
|
||||
|
||||
.. _Why_can't_I_set_a_breakpoint:
|
||||
|
||||
Why can't I set a breakpoint?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -150,10 +138,6 @@ loaded <#How_do_I_set_a_breakpoint_when_a_component_is_loaded.3F>`__ and
|
||||
`breaking on a library
|
||||
load <#How_do_I_set_a_breakpoint_when_a_component_is_loaded.3F>`__.
|
||||
|
||||
|
||||
|
||||
.. _How_do_I_display_PRUnichar.27s.3F:
|
||||
|
||||
How do I display PRUnichar's?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -237,8 +221,6 @@ functions. <#This_is_hard._Give_me_a_.gdbinit_that_works.>`__
|
||||
- Define a small helper function "punichar" in #ifdef NS_DEBUG code
|
||||
somewhere.
|
||||
|
||||
.. _How_do_I_display_an_nsString.3F:
|
||||
|
||||
How do I display an nsString?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -262,8 +244,6 @@ returned length of your string):
|
||||
You can of course use any of the above unichar-printing routines instead
|
||||
of x/s.
|
||||
|
||||
.. _This_is_hard._Give_me_a_.gdbinit_that_works.:
|
||||
|
||||
This is hard. Give me a .gdbinit that works.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -275,8 +255,6 @@ several function definitions including:
|
||||
- "pu" which will display a (PRUnichar \*) string.
|
||||
- "ps" which will display a nsString.
|
||||
|
||||
.. _How_do_I_determine_the_concrete_type_of_an_object_pointed_to_by_an_interface_pointer.3F:
|
||||
|
||||
How do I determine the concrete type of an object pointed to by an interface pointer?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -303,8 +281,6 @@ loaded? <#How_do_I_see_what_libraries_I_already_have_loaded.3F>`__
|
||||
|
||||
Or use the gdb command ``set print object on``.
|
||||
|
||||
.. _How_can_I_debug_JavaScript_from_gdb:
|
||||
|
||||
How can I debug JavaScript from gdb?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -318,8 +294,6 @@ JS stack in addition to the C++ stack.
|
||||
See `https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_JavaScript </en-US/docs/Mozilla/Debugging/Debugging_JavaScript>`__
|
||||
for more JS debugging tricks.
|
||||
|
||||
.. _How_can_I_debug_race_conditions_and.2For_how_can_I_make_something_different_happen_at_NS_ASSERTION_time.3F:
|
||||
|
||||
How can I debug race conditions and/or how can I make something different happen at NS_ASSERTION time?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -331,13 +305,11 @@ How can I debug race conditions and/or how can I make something different happen
|
||||
change the behavior of ``NS_ASSERTION`` (nsDebug::Break) using the
|
||||
``XPCOM_DEBUG_BREAK`` environment variable.
|
||||
|
||||
.. _How_do_I_run_the_debugger_in_emacsxemacs:
|
||||
|
||||
How do I run the debugger in emacs/xemacs?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Emacs and XEmacs contain modes for doing visual debugging. However, you
|
||||
might want to set up environment variables, specifiying the loading of
|
||||
might want to set up environment variables, specifying the loading of
|
||||
symbols and components. The easiest way to set up these is to use the
|
||||
``run-mozilla.sh`` script, located in the dist/bin directory of your
|
||||
build. This script sets up the environment to run the editor, shell,
|
||||
@ -358,8 +330,6 @@ wish. For example:
|
||||
moz_debug=0
|
||||
moz_debugger=
|
||||
|
||||
.. _GDB_5_used_to_work_for_me_but_now_Firefox_won't_start._What_can_I_do:
|
||||
|
||||
GDB 5 used to work for me, but now Firefox won't start. What can I do?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -371,8 +341,6 @@ change to gdb has fixed this. Download and build `the latest version of
|
||||
Insight <https://sources.redhat.com/insight/>`__, or if you don't want a
|
||||
GUI, `the latest version of gdb <https://sources.redhat.com/gdb/>`__.
|
||||
|
||||
.. _.22run.22_or_.22prun.22_in_GDB_fails_with_.22error_in_loading_shared_libraries..22:
|
||||
|
||||
"run" or "prun" in GDB fails with "error in loading shared libraries."
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -397,8 +365,6 @@ that file affect your program. You may wish to move the setting of
|
||||
environment variables to files that are only run when you sign on, such
|
||||
as '.login' or '.profile'.*
|
||||
|
||||
.. _Debian.27s_GDB_doesn.27t_work._What_do_I_do.3F:
|
||||
|
||||
Debian's GDB doesn't work. What do I do?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -411,8 +377,6 @@ threaded software. These fixes are expected to be merged into GDB, which
|
||||
will fix the problem for Debian Linux. (via `Bruce
|
||||
Mitchener <mailto:bruce@cybersight.com>`__)
|
||||
|
||||
.. _Mozilla_is_aborting._Where_do_I_set_a_breakpoint_to_find_out_where_it_is_exiting.3F:
|
||||
|
||||
Firefox is aborting. Where do I set a breakpoint to find out where it is exiting?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -425,8 +389,6 @@ can stop at two places:
|
||||
(gdb) b abort
|
||||
(gdb) b exit
|
||||
|
||||
.. _I_keep_getting_a_SIG32_in_the_debugger._How_do_I_fix_it.3F:
|
||||
|
||||
I keep getting a SIGSEGV in JS/JIT code under gdb even though there is no crash when gdb is not attached. How do I fix it?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -435,8 +397,6 @@ the shorter and easier-to-remember JS_NO_SIGNALS). For an explanation,
|
||||
read `Jan's blog
|
||||
post <https://www.jandemooij.nl/blog/2014/02/18/using-segfaults-to-interrupt-jit-code/>`__.
|
||||
|
||||
.. _I_keep_getting_a_SIG32_in_the_debugger._How_do_I_fix_it.3F:
|
||||
|
||||
I keep getting a SIG32 in the debugger. How do I fix it?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -459,8 +419,6 @@ libpthread is stripped in ``file /lib/libpthread*`` and looking for
|
||||
glibc after adding ``"nostrip"`` to your ``FEATURES`` in
|
||||
``/etc/make.conf``.
|
||||
|
||||
.. _How_do_I_get_useful_stack_traces_inside_system_libraries.3F:
|
||||
|
||||
How do I get useful stack traces inside system libraries?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -468,8 +426,6 @@ Many Linux distributions provide separate packages with debugging
|
||||
information for system libraries, such as gdb, Valgrind, profiling
|
||||
tools, etc., to give useful stack traces via system libraries.
|
||||
|
||||
.. _Fedora_8:
|
||||
|
||||
Fedora
|
||||
^^^^^^
|
||||
|
||||
@ -504,8 +460,6 @@ This can be done manually using:
|
||||
libXrender-debuginfo libbonobo-debuginfo libgnome-debuginfo \
|
||||
libselinux-debuginfo pango-debuginfo popt-debuginfo scim-bridge-debuginfo
|
||||
|
||||
.. _Ubuntu_8.04:
|
||||
|
||||
Ubuntu 8.04
|
||||
^^^^^^^^^^^
|
||||
|
||||
@ -520,8 +474,6 @@ though not all of them. To install them, run:
|
||||
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):
|
||||
|
||||
Debugging electrolysis (e10s)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -540,8 +492,6 @@ To get the child process id use:
|
||||
|
||||
MOZ_DEBUG_CHILD_PROCESS=1 mach run
|
||||
|
||||
.. _See_also:
|
||||
|
||||
See also
|
||||
~~~~~~~~~
|
||||
|
||||
|
||||
@ -3,8 +3,6 @@ Debugging Mozilla with LLDB
|
||||
|
||||
See http://lldb.llvm.org/index.html.
|
||||
|
||||
.. _Mozilla-specific_lldb_settings:
|
||||
|
||||
Mozilla-specific lldb settings
|
||||
------------------------------
|
||||
|
||||
@ -19,7 +17,7 @@ LLDB to debug Gecko <http://mcc.id.au/blog/2014/01/lldb-gecko>`__ blog
|
||||
post.
|
||||
|
||||
The in-tree ``.lldbinit`` should be loaded automatically in most cases
|
||||
when runnning lldb from the command line (e.g. using
|
||||
when running lldb from the command line (e.g. using
|
||||
```mach`` </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
|
||||
@ -46,13 +44,9 @@ XCode.
|
||||
doesn't fix things then try closing Xcode/lldb, doing a clobber
|
||||
build, reopening Xcode/lldb, and restarting your debugging session.
|
||||
|
||||
.. _Starting_a_debugging_session:
|
||||
|
||||
Starting a debugging session
|
||||
----------------------------
|
||||
|
||||
.. _Attaching_to_an_existing_process:
|
||||
|
||||
Attaching to an existing process
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -64,8 +58,6 @@ You can attach to Firefox with following command:
|
||||
|
||||
Some versions of lldb causes crashes after attaching to Firefox.
|
||||
|
||||
.. _Running_a_new_process:
|
||||
|
||||
Running a new process
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@ -4,8 +4,6 @@ Debugging Mozilla with Valgrind
|
||||
This page describes how to use Valgrind (specifically, its Memcheck
|
||||
tool) to find memory errors.
|
||||
|
||||
.. _Supported_platforms:
|
||||
|
||||
Supported platforms
|
||||
-------------------
|
||||
|
||||
@ -24,8 +22,6 @@ of a rough ride.
|
||||
leak reports with caution.
|
||||
- Valgrind has been known to cause kernel panics, for unknown reasons.
|
||||
|
||||
.. _Where_to_get_Valgrind:
|
||||
|
||||
Where to get Valgrind
|
||||
---------------------
|
||||
|
||||
@ -40,13 +36,9 @@ Make sure you have version 3.10.1 or later of Valgrind. Newer versions
|
||||
tend to have better compatibility with both Firefox's JITs and newer
|
||||
toolchain components (compiler, libc and linker versions).
|
||||
|
||||
.. _Basics:
|
||||
|
||||
Basics
|
||||
------
|
||||
|
||||
.. _Build:
|
||||
|
||||
Build
|
||||
~~~~~
|
||||
|
||||
@ -60,8 +52,6 @@ accuracy.
|
||||
ac_add_options --enable-valgrind
|
||||
ac_add_options --enable-optimize="-g -O2"
|
||||
|
||||
.. _Run:
|
||||
|
||||
Run
|
||||
~~~
|
||||
|
||||
@ -69,8 +59,6 @@ Note that programs run *much* more slowly under Valgrind than they do
|
||||
natively. Slow-downs of 20x or 30x aren't unexpected, and it's slower on
|
||||
Mac than on Linux. Don't try this on an underpowered machine.
|
||||
|
||||
.. _Linux:
|
||||
|
||||
Linux
|
||||
^^^^^
|
||||
|
||||
@ -99,8 +87,6 @@ Also, run with the following environment variable set.
|
||||
This is necessary to get the Gnome system libraries to use plain
|
||||
``malloc`` instead of pool allocators.
|
||||
|
||||
.. _Mac:
|
||||
|
||||
Mac
|
||||
^^^
|
||||
|
||||
@ -113,13 +99,9 @@ On Mac, run Valgrind with the following options.
|
||||
The ``--dsymutil`` option ensures line number information is present in
|
||||
stack traces.
|
||||
|
||||
.. _Advanced_usage:
|
||||
|
||||
Advanced usage
|
||||
--------------
|
||||
|
||||
.. _Shared_suppression_files:
|
||||
|
||||
Shared suppression files
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -127,8 +109,6 @@ Shared suppression files
|
||||
contains the suppression files used by the periodic Valgrind jobs on
|
||||
Tinderbox. Some of these files are platform-specific.
|
||||
|
||||
.. _Running_mochitests_under_Valgrind:
|
||||
|
||||
Running mochitests under Valgrind?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -147,8 +127,6 @@ mochitests-plain on Valgrind in about 8 CPU hours on a Core i4910
|
||||
(Haswell) machine. Maximum process size is 5.4G, of which about 80% is
|
||||
in memory. Runs of small subsets of mochitests take far less memory.
|
||||
|
||||
.. _Bits_and_pieces:
|
||||
|
||||
Bits and pieces
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
@ -174,8 +152,6 @@ unless you are hunting down a specific uninitialised value error. But if
|
||||
you are hunting down such an error, it's extremely helpful and worth
|
||||
waiting for.
|
||||
|
||||
.. _Additional_help:
|
||||
|
||||
Additional help
|
||||
---------------
|
||||
|
||||
|
||||
@ -31,8 +31,6 @@ http://stackframe.blogspot.com/ for more details).
|
||||
See also the official VMWare documentation
|
||||
http://www.vmware.com/pdf/ws7_visualstudio_debug.pdf.
|
||||
|
||||
.. _Hardware_Requirements:
|
||||
|
||||
Hardware Requirements
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -41,8 +39,6 @@ performance when replay debugging. We recommend a quad core i7 or Xeon
|
||||
chip. We also recommend at least 8 GB RAM and an SSD with at least 256
|
||||
GB space.
|
||||
|
||||
.. _Setting_up_the_Host_computer:
|
||||
|
||||
Setting up the Host computer
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -70,8 +66,6 @@ Installation file with Tools. We've had success with version 7.1.3. This
|
||||
must be installed after Visual Studio so that Workstation's Virtual
|
||||
Integrated Debugger plugin gets installed into Visual Studio.
|
||||
|
||||
.. _Setting_up_the_Guest_Virtual_Machine:
|
||||
|
||||
Setting up the Guest Virtual Machine
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -128,8 +122,6 @@ Turn off "Take snapshots in background" in Workstation > Edit >
|
||||
Preferences > Priority. This makes snapshots faster, but blocks the VM
|
||||
while taking them.
|
||||
|
||||
.. _Record_and_Replay_of_Nightly_Builds:
|
||||
|
||||
Record and Replay of Nightly Builds
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -147,8 +139,6 @@ relatively easy to use them for record and replay debugging.
|
||||
- Replay! When prompted, you may have to inform MSVC of the location of
|
||||
guestdlls and installdir/components.
|
||||
|
||||
.. _Building_Firefox_for_Record_Replay:
|
||||
|
||||
Building Firefox for Record Replay
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -182,8 +172,6 @@ specifying an object dir, and the following options:
|
||||
| You can run now mochitests with:
|
||||
| ``$ python mochitest/runtests.py --appname firefox/firefox.exe --utility-path=firefox --certificate-path=certs --autorun --close-when-done --console-level=INFO --log-file=./mochitest-plain.log --file-level=INFO``
|
||||
|
||||
.. _Configuring_Visual_Studio_for_Replay_Debugging:
|
||||
|
||||
Configuring Visual Studio for Replay Debugging
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -214,8 +202,6 @@ http://msdl.microsoft.com/download/symbols as a symbol location. If you
|
||||
run Firefox from MSVC in the Host, and the symbols will be downloaded
|
||||
immediately.
|
||||
|
||||
.. _Creating_a_Recording:
|
||||
|
||||
Creating a Recording
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -235,8 +221,6 @@ redirect it to a log file, and copy the log file out to your Host after
|
||||
you've recorded a test failure. If you don't copy the log file out to
|
||||
the Host, you can't view the log file while replaying.
|
||||
|
||||
.. _Replaying_a_Recording:
|
||||
|
||||
Replaying a Recording
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -261,8 +245,6 @@ got a copy of every DLL loaded in the guest in your GuestDLLs directory
|
||||
on the host. There's probably a DLL in the Guest's C:\Windows\SxS
|
||||
directory that you need in the Host's GuestDLL folder.
|
||||
|
||||
.. _Workflow:
|
||||
|
||||
Workflow
|
||||
~~~~~~~~
|
||||
|
||||
|
||||
@ -30,16 +30,12 @@ Stats <https://crash-stats.mozilla.com/documentation/memory_dump_access/>`__.
|
||||
Each crash report has the following tabs: Details, Metadata, Modules,
|
||||
Raw Dump, Extensions, and (optional) Correlations.
|
||||
|
||||
.. _Details_tab:
|
||||
|
||||
Details tab
|
||||
-----------
|
||||
|
||||
The Details tab is the first place to look because it contains the most
|
||||
important pieces of information.
|
||||
|
||||
.. _Primary_fields:
|
||||
|
||||
Primary fields
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
@ -64,7 +60,7 @@ superusers <http://adrian.gaudebert.fr/blog/post/2014/12/02/socorro-super-search
|
||||
The fields present in this tab vary depending on the crash kind. Not all
|
||||
fields are always present.
|
||||
|
||||
The "Signature" field is the main identifer or label for a crash report.
|
||||
The "Signature" field is the main identifier or label for a crash report.
|
||||
Rather than considering each crash report in isolation, we want to put
|
||||
crash reports into clusters so we can deal with groups of them at once.
|
||||
An ideal clustering algorithm would put all crash reports with the same
|
||||
@ -165,8 +161,6 @@ memory report are shown in the Details tab, each one having a field name
|
||||
starting with "MR:", short for "memory report". The full memory report
|
||||
can be obtained in the Raw Dump tab (see below).
|
||||
|
||||
.. _Bug-related_information:
|
||||
|
||||
Bug-related information
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -183,8 +177,6 @@ fields pre-filled, such as the crash signature.
|
||||
The "Related Bugs" section shows related bug reports, as determined by
|
||||
the crash signature.
|
||||
|
||||
.. _Stack_traces:
|
||||
|
||||
Stack traces
|
||||
~~~~~~~~~~~~
|
||||
|
||||
@ -229,8 +221,6 @@ problem; many of them will be waiting on some kind of response, as shown
|
||||
by a top stack frame containing a function like
|
||||
``NtWaitForSingleObject`` or ``ZwWaitForMultipleObjects``.
|
||||
|
||||
.. _Metadata_tab:
|
||||
|
||||
Metadata tab
|
||||
------------
|
||||
|
||||
@ -240,8 +230,6 @@ raw crash report, ordered alphabetically by field name, but with
|
||||
privacy-sensitive fields shown only to users with minidump access. There
|
||||
is some overlap with the fields shown in the Details tab.
|
||||
|
||||
.. _Modules_tab:
|
||||
|
||||
Modules tab
|
||||
-----------
|
||||
|
||||
@ -262,8 +250,6 @@ the "Correlations" tab (see below).
|
||||
says that files lacking version/debug identifier/debug filename are
|
||||
likely to be malware.
|
||||
|
||||
.. _Raw_Dump_tab:
|
||||
|
||||
Raw Dump tab
|
||||
------------
|
||||
|
||||
@ -290,8 +276,6 @@ These links are to the following items.
|
||||
link.
|
||||
#. The unredacted crash report, which has additional information.
|
||||
|
||||
.. _Extensions_tab:
|
||||
|
||||
Extensions tab
|
||||
--------------
|
||||
|
||||
@ -317,8 +301,6 @@ This information is useful because some crashes are caused by
|
||||
extensions. Correlations between extensions and crash signatures can be
|
||||
seen in the "Correlations" tab (see below).
|
||||
|
||||
.. _Correlations_tab:
|
||||
|
||||
Correlations tab
|
||||
----------------
|
||||
|
||||
@ -326,8 +308,6 @@ This tab is only shown when crash-stats identifies correlations between
|
||||
a crash and modules or extensions that are present, which happens
|
||||
occasionally.
|
||||
|
||||
.. _See_also:
|
||||
|
||||
See also
|
||||
--------
|
||||
|
||||
|
||||
@ -24,13 +24,10 @@ development process and source code documentation.
|
||||
.. toctree::
|
||||
:caption: Debugging
|
||||
:maxdepth: 1
|
||||
|
||||
debugging/debugging_a_minidump
|
||||
debugging/debugging_mozilla_with_gdb
|
||||
debugging/debugging_mozilla_with_lldb
|
||||
debugging/debugging_mozilla_with_valgrind
|
||||
debugging/record_and_replay_debugging_firefox
|
||||
debugging/understanding_crash_reports
|
||||
:glob:
|
||||
|
||||
debugging/*
|
||||
|
||||
|
||||
.. toctree::
|
||||
:caption: Additional Information
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
.. _What_is_Memory_Sanitizer:
|
||||
Memory Sanitizer
|
||||
================
|
||||
|
||||
What is Memory Sanitizer?
|
||||
-------------------------
|
||||
@ -12,8 +13,6 @@ not able to observe memory initialization in uninstrumented libraries.
|
||||
More information on MSan can be found on `the Memory Sanitizer
|
||||
wiki <https://github.com/google/sanitizers/wiki/MemorySanitizer>`__.
|
||||
|
||||
.. _Public_Builds:
|
||||
|
||||
Public Builds
|
||||
-------------
|
||||
|
||||
@ -21,13 +20,9 @@ Public Builds
|
||||
|
||||
**Note:** No public builds are available at this time yet.
|
||||
|
||||
.. _Manual_Build:
|
||||
|
||||
Manual Build
|
||||
------------
|
||||
|
||||
.. _Build_prerequisites:
|
||||
|
||||
Build prerequisites
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -36,8 +31,6 @@ Build prerequisites
|
||||
**Note:** MemorySanitizer requires **64-bit Linux** to work. Other
|
||||
platforms/operating systems are not supported.
|
||||
|
||||
.. _LLVMClang:
|
||||
|
||||
LLVM/Clang
|
||||
^^^^^^^^^^
|
||||
|
||||
@ -48,8 +41,6 @@ recent Clang version, such as Clang 3.7+.
|
||||
You can find precompiled binaries for LLVM/Clang on `the LLVM releases
|
||||
page <https://releases.llvm.org/download.html>`__.
|
||||
|
||||
.. _Building_Firefox:
|
||||
|
||||
Building Firefox
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -61,8 +52,6 @@ Building Firefox
|
||||
configuration provided here is untested and without an appropriately
|
||||
instrumented userland, it will cause false positives.**
|
||||
|
||||
.. _Getting_the_source:
|
||||
|
||||
Getting the source
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -70,8 +59,6 @@ If you don't have a source code repository clone yet, you need to `get
|
||||
yourself a clone of
|
||||
Mozilla-central </en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial>`__.
|
||||
|
||||
.. _Adjusting_the_build_configuration:
|
||||
|
||||
Adjusting the build configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -119,24 +106,18 @@ content in your Mozilla-central directory:
|
||||
ac_add_options --enable-optimize="-O2 -gline-tables-only"
|
||||
ac_add_options --disable-debug
|
||||
|
||||
.. _Starting_the_build_process:
|
||||
|
||||
Starting the build process
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Now you start the build process using the regular ``make -f client.mk``
|
||||
command.
|
||||
|
||||
.. _Starting_Firefox:
|
||||
|
||||
Starting Firefox
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
After the build has completed, you can start Firefox from the ``objdir``
|
||||
as usual.
|
||||
|
||||
.. _Building_the_JavaScript_shell:
|
||||
|
||||
Building the JavaScript shell
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -184,8 +165,6 @@ subdirectory with that name.
|
||||
make -j 8
|
||||
fi
|
||||
|
||||
.. _Using_LLVM_Symbolizer_for_fasterbetter_traces:
|
||||
|
||||
Using LLVM Symbolizer for faster/better traces
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -197,8 +176,6 @@ found on the ``PATH``. If your ``llvm-symbolizer`` lives outside the
|
||||
``PATH``, you can set the ``MSAN_SYMBOLIZER_PATH`` environment variable
|
||||
to point to your symbolizer binary.
|
||||
|
||||
.. _Ignoring_known_issues:
|
||||
|
||||
**Ignoring known issues**
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user