[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to emacs/etc/DEBUG,v
From: |
Glenn Morris |
Subject: |
[Emacs-diffs] Changes to emacs/etc/DEBUG,v |
Date: |
Fri, 13 Apr 2007 02:58:18 +0000 |
CVSROOT: /sources/emacs
Module name: emacs
Changes by: Glenn Morris <gm> 07/04/13 02:58:17
Index: DEBUG
===================================================================
RCS file: /sources/emacs/emacs/etc/DEBUG,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -b -r1.46 -r1.47
--- DEBUG 26 Mar 2007 03:28:55 -0000 1.46
+++ DEBUG 13 Apr 2007 02:58:17 -0000 1.47
@@ -567,7 +567,7 @@
Once you discover the corrupted Lisp object or data structure, grep
the sources for its uses and try to figure out what could cause the
-corruption. If looking at the sources doesn;t help, you could try
+corruption. If looking at the sources doesn't help, you could try
setting a watchpoint on the corrupted data, and see what code modifies
it in some invalid way. (Obviously, this technique is only useful for
data that is modified only very rarely.)
@@ -731,7 +731,7 @@
disassembly to determine exactly what code is being run--the
disassembly will probably show several source lines followed by a
block of assembler for those lines. The actual point where Emacs
-crashes will be one of those source lines, but not neccesarily the one
+crashes will be one of those source lines, but not necessarily the one
that the debugger reports.
Another problematic area with the MS debugger is with variables that
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Emacs-diffs] Changes to emacs/etc/DEBUG,v,
Glenn Morris <=