diff options
| -rw-r--r-- | etc/DEBUG | 4 |
1 files changed, 2 insertions, 2 deletions
| @@ -567,7 +567,7 @@ are involved in the crash. | |||
| 567 | 567 | ||
| 568 | Once you discover the corrupted Lisp object or data structure, grep | 568 | Once you discover the corrupted Lisp object or data structure, grep |
| 569 | the sources for its uses and try to figure out what could cause the | 569 | the sources for its uses and try to figure out what could cause the |
| 570 | corruption. If looking at the sources doesn;t help, you could try | 570 | corruption. If looking at the sources doesn't help, you could try |
| 571 | setting a watchpoint on the corrupted data, and see what code modifies | 571 | setting a watchpoint on the corrupted data, and see what code modifies |
| 572 | it in some invalid way. (Obviously, this technique is only useful for | 572 | it in some invalid way. (Obviously, this technique is only useful for |
| 573 | data that is modified only very rarely.) | 573 | 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 | |||
| 731 | disassembly to determine exactly what code is being run--the | 731 | disassembly to determine exactly what code is being run--the |
| 732 | disassembly will probably show several source lines followed by a | 732 | disassembly will probably show several source lines followed by a |
| 733 | block of assembler for those lines. The actual point where Emacs | 733 | block of assembler for those lines. The actual point where Emacs |
| 734 | crashes will be one of those source lines, but not neccesarily the one | 734 | crashes will be one of those source lines, but not necessarily the one |
| 735 | that the debugger reports. | 735 | that the debugger reports. |
| 736 | 736 | ||
| 737 | Another problematic area with the MS debugger is with variables that | 737 | Another problematic area with the MS debugger is with variables that |