diff options
| author | Glenn Morris <rgm@gnu.org> | 2007-04-13 02:58:17 +0000 |
|---|---|---|
| committer | Glenn Morris <rgm@gnu.org> | 2007-04-13 02:58:17 +0000 |
| commit | 2fbcf1743ee4f477313dfd6d26587c76f16912f0 (patch) | |
| tree | 430eaae16fc85820467d46d1520e59e80ef47edb /etc/DEBUG | |
| parent | a7da3bc55c791df798d550c2efc521996b827faf (diff) | |
| download | emacs-2fbcf1743ee4f477313dfd6d26587c76f16912f0.tar.gz | |
Fix typos.
Diffstat (limited to 'etc/DEBUG')
| -rw-r--r-- | etc/DEBUG | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/etc/DEBUG b/etc/DEBUG index 97e1f015a05..ea4e14866ca 100644 --- a/etc/DEBUG +++ b/etc/DEBUG @@ -567,7 +567,7 @@ are involved in the crash. 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 @@ prints the backtrace for a crash. It is usually best to look at the 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 |