# HG changeset patch # User Glenn Morris # Date 1176433097 0 # Node ID 563a04f93ea0f287d2be25bbe1364fe4eff2af13 # Parent 0913bc126b058052674894d2e4deac82a6a50cb6 Fix typos. diff -r 0913bc126b05 -r 563a04f93ea0 etc/DEBUG --- a/etc/DEBUG Fri Apr 13 02:55:28 2007 +0000 +++ b/etc/DEBUG Fri Apr 13 02:58:17 2007 +0000 @@ -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