Clean up.

[pintos-anon] / doc / debug.texi

diff --git a/doc/debug.texi b/doc/debug.texi
index 35e7c4af5e9e0fcb1caf8afa9f8867f898b5796e..f93eeda3ad0251375e96f8ac02b31ad06bd0aa60 100644 (file)
--- a/doc/debug.texi
+++ b/doc/debug.texi
@@ -217,13 +217,8 @@ The fifth and sixth lines are the interrupt handler entry path.
 The remaining lines are for addresses below @code{PHYS_BASE}.  This
 means that they refer to addresses in the user program, not in the
 kernel.  If you know what user program was running when the kernel
 The remaining lines are for addresses below @code{PHYS_BASE}.  This
 means that they refer to addresses in the user program, not in the
 kernel.  If you know what user program was running when the kernel

-panicked, you can re-run @command{backtrace} on the user program.  You
-need to have compiled the user program with debug symbols enabled for
-this to be useful.  Instructions for doing so are included in
-@file{pintos/src/Makefile.userprog}.
-
-In this case, we rerun @command{backtrace} like so (typing the command
-on a single line, of course):
+panicked, you can re-run @command{backtrace} on the user program, like
+so: (typing the command on a single line, of course):

 
 @example
 ~/cs140/pintos/src/utils/backtrace grow-too-big 0xc0106eff 0xc01102fb
 
 @example
 ~/cs140/pintos/src/utils/backtrace grow-too-big 0xc0106eff 0xc01102fb


@@ -305,14 +300,6 @@ address.
 (Use a @samp{0x} prefix to specify an address in hex.)
 @end table
 
 (Use a @samp{0x} prefix to specify an address in hex.)
 @end table
 

-You might notice that @command{gdb} tends to show code being executed
-in an order different from the order in the source.  That is, the
-current statement jumps around seemingly randomly.  This is due to
-GCC's optimizer, which does tend to reorder code.  If it bothers you,
-you can turn off optimization by editing
-@file{pintos/src/Make.config}, removing @option{-O3} from the
-@code{CFLAGS} definition.
-

 If you notice other strange behavior while using @command{gdb}, there
 are three possibilities.  The first is that there is a bug in your
 modified Pintos.  The second is that there is a bug in Bochs's
 If you notice other strange behavior while using @command{gdb}, there
 are three possibilities.  The first is that there is a bug in your
 modified Pintos.  The second is that there is a bug in Bochs's


@@ -387,17 +374,18 @@ above, a good place to start adding @func{printf}s is
 @node Debugging Tips
 @section Tips
 
 @node Debugging Tips
 @section Tips
 

-The page allocator in @file{threads/palloc.c} clears all the bytes in
-pages to @t{0xcc} when they are freed.  Thus, if you see an attempt to
+The page allocator in @file{threads/palloc.c} and the block allocator in
+@file{threads/malloc.c} both clear all the bytes in pages and blocks to
+@t{0xcc} when they are freed.  Thus, if you see an attempt to

 dereference a pointer like @t{0xcccccccc}, or some other reference to
 @t{0xcc}, there's a good chance you're trying to reuse a page that's
 dereference a pointer like @t{0xcccccccc}, or some other reference to
 @t{0xcc}, there's a good chance you're trying to reuse a page that's

-already been freed.  Also, byte @t{0xcc} is the CPU opcode for
-``invoke interrupt 3,'' so if you see an error like @code{Interrupt
-0x03 (#BP Breakpoint Exception)}, Pintos tried to execute code in a
-freed page.
-
-Similarly, the block allocator in @file{threads/malloc.c} clears all
-the bytes in freed blocks to @t{0xcd}.  The two bytes @t{0xcdcd} are
-a CPU opcode for ``invoke interrupt @t{0xcd},'' so @code{Interrupt
-0xcd (unknown)} is a good sign that you tried to execute code in a
-block freed with @func{free}.
+already been freed.  Also, byte @t{0xcc} is the CPU opcode for ``invoke
+interrupt 3,'' so if you see an error like @code{Interrupt 0x03 (#BP
+Breakpoint Exception)}, Pintos tried to execute code in a freed page or
+block.
+
+An assertion failure on the expression @code{sec_no < d->capacity}
+indicates that Pintos tried to access a file through an inode that has
+been closed and freed.  Freeing an inode clears its starting sector
+number to @t{0xcccccccc}, which is not a valid sector number for disks
+smaller than about 1.6 TB.