nt/INSTALL: Elaborate on debugging fatal errors.

diff --git a/nt/ChangeLog b/nt/ChangeLog
index 8de94033196b2b2efd27584bd0495eb0e4e8e87c..3aa7bd658e4e71e241cd13e324c55c8a1eef2f77 100644 (file)
--- a/nt/ChangeLog
+++ b/nt/ChangeLog
@@ -1,3 +1,7 @@
+2011-11-25  Eli Zaretskii  <eliz@gnu.org>
+
+       * INSTALL: Elaborate on debugging fatal errors.
+
 2011-11-15  Eli Zaretskii  <eliz@gnu.org>
 
        * README.W32: Update the GTK Windows download URL for libpng.

diff --git a/nt/INSTALL b/nt/INSTALL
index bb621dceb6be3005b74ea3b535daeaa2a7bc04a8..7dc027f06f49f452dfb59635e67b19b1adb3c2f3 100644 (file)
--- a/nt/INSTALL
+++ b/nt/INSTALL
@@ -599,6 +599,30 @@
   the debugger, and you will be able to debug the cause of the fatal
   error.
 
+  The single most important thing to find out when Emacs aborts or
+  crashes is where did that happen in the Emacs code.  This is called
+  "backtrace".
+
+  Emacs on Windows uses more than one thread.  When Emacs aborts due
+  to a fatal error, the current thread may not be the application
+  thread running Emacs code.  Therefore, to produce a meaningful
+  backtrace from a debugger, you need to iunstruct it to show the
+  backtrace for every thread.  With GDB, you do it like this:
+
+   (gdb) thread apply all backtrace
+
+  To run Emacs under a debugger to begin with, simply start it from
+  the debugger.  With GDB, chdir to the `src' directory (if you have
+  the source tree) or to a directory with the `.gdbinit' file (if you
+  don't have the source tree), and type these commands:
+
+    C:\whatever\src> gdb x:\path\to\emacs.exe
+    (gdb) run <ARGUMENTS TO EMACS>
+
+  Thereafter, use Emacs as usual; you can minimize the debugger
+  window, if you like.  The debugger will take control if and when
+  Emacs crashes.
+
   Emacs functions implemented in C use a naming convention that reflects
   their names in lisp.  The names of the C routines are the lisp names
   prefixed with 'F', and with dashes converted to underscores.  For