-@node Debugging Tools, Development Tools, Project Documentation, Top
+@node Debugging Tools
@appendix Debugging Tools
Many tools lie at your disposal for debugging Pintos. This appendix
Don't underestimate the value of @func{printf}. The way
@func{printf} is implemented in Pintos, you can call it from
practically anywhere in the kernel, whether it's in a kernel thread or
-an interrupt handler, almost regardless of what locks are held (but see
-@ref{printf Reboots} for a counterexample).
+an interrupt handler, almost regardless of what locks are held.
@func{printf} is useful for more than just examining data.
It can also help figure out when and where something goes wrong, even
when the kernel crashes or panics without a useful error message. The
-strategy is to sprinkle calls to @func{print} with different strings
+strategy is to sprinkle calls to @func{printf} with different strings
(e.g.@: @code{"<1>"}, @code{"<2>"}, @dots{}) throughout the pieces of
code you suspect are failing. If you don't even see @code{<1>} printed,
then something bad happened before that point, if you see @code{<1>}
functions that were running at the time of the panic. You can also
insert a call to @func{debug_backtrace}, prototyped in
@file{<debug.h>}, to print a backtrace at any point in your code.
+@func{debug_backtrace_all}, also declared in @file{<debug.h>},
+prints backtraces of all threads.
The addresses in a backtrace are listed as raw hexadecimal numbers,
which are difficult to interpret. We provide a tool called
call A), then it's a good sign that you're corrupting a kernel
thread's stack, because the backtrace is extracted from the stack.
Alternatively, it could be that the @file{kernel.o} you passed to
-@command{backtrace} does not correspond to the kernel that produced
+@command{backtrace} is not the same kernel that produced
the backtrace.
-Sometimes backtraces can be confusing without implying corruption.
+Sometimes backtraces can be confusing without any corruption.
Compiler optimizations can cause surprising behavior. When a function
has called another function as its final action (a @dfn{tail call}), the
calling function may not appear in a backtrace at all. Similarly, when
The backtrace output would then look something like this:
@example
-0xc0106eff: debug_panic (../../lib/debug.c:86)
-0xc01102fb: file_seek (../../filesys/file.c:405)
-0xc010dc22: seek (../../userprog/syscall.c:744)
-0xc010cf67: syscall_handler (../../userprog/syscall.c:444)
-0xc0102319: intr_handler (../../threads/interrupt.c:334)
-0xc010325a: ?? (threads/intr-stubs.S:1554)
-0x804812c: ?? (??:0)
-0x8048a96: ?? (??:0)
-0x8048ac8: ?? (??:0)
+0xc0106eff: debug_panic (lib/debug.c:86)
+0xc01102fb: file_seek (filesys/file.c:405)
+0xc010dc22: seek (userprog/syscall.c:744)
+0xc010cf67: syscall_handler (userprog/syscall.c:444)
+0xc0102319: intr_handler (threads/interrupt.c:334)
+0xc010325a: intr_entry (threads/intr-stubs.S:38)
+0x0804812c: (unknown)
+0x08048a96: (unknown)
+0x08048ac8: (unknown)
@end example
(You will probably not see exactly the same addresses if you run the
so: (typing the command on a single line, of course):
@example
-backtrace grow-too-big 0xc0106eff 0xc01102fb 0xc010dc22 0xc010cf67
-0xc0102319 0xc010325a 0x804812c 0x8048a96 0x8048ac8
+backtrace tests/filesys/extended/grow-too-big 0xc0106eff 0xc01102fb
+0xc010dc22 0xc010cf67 0xc0102319 0xc010325a 0x804812c 0x8048a96
+0x8048ac8
@end example
The results look like this:
@example
-0xc0106eff: ?? (??:0)
-0xc01102fb: ?? (??:0)
-0xc010dc22: ?? (??:0)
-0xc010cf67: ?? (??:0)
-0xc0102319: ?? (??:0)
-0xc010325a: ?? (??:0)
-0x804812c: test_main (../../tests/filesys/extended/grow-too-big.c:20)
-0x8048a96: main (../../tests/main.c:10)
-0x8048ac8: _start (../../lib/user/entry.c:9)
+0xc0106eff: (unknown)
+0xc01102fb: (unknown)
+0xc010dc22: (unknown)
+0xc010cf67: (unknown)
+0xc0102319: (unknown)
+0xc010325a: (unknown)
+0x0804812c: test_main (...xtended/grow-too-big.c:20)
+0x08048a96: main (tests/main.c:10)
+0x08048ac8: _start (lib/user/entry.c:9)
+@end example
+
+You can even specify both the kernel and the user program names on
+the command line, like so:
+
+@example
+backtrace kernel.o tests/filesys/extended/grow-too-big 0xc0106eff
+0xc01102fb 0xc010dc22 0xc010cf67 0xc0102319 0xc010325a 0x804812c
+0x8048a96 0x8048ac8
+@end example
+
+The result is a combined backtrace:
+
+@example
+In kernel.o:
+0xc0106eff: debug_panic (lib/debug.c:86)
+0xc01102fb: file_seek (filesys/file.c:405)
+0xc010dc22: seek (userprog/syscall.c:744)
+0xc010cf67: syscall_handler (userprog/syscall.c:444)
+0xc0102319: intr_handler (threads/interrupt.c:334)
+0xc010325a: intr_entry (threads/intr-stubs.S:38)
+In tests/filesys/extended/grow-too-big:
+0x0804812c: test_main (...xtended/grow-too-big.c:20)
+0x08048a96: main (tests/main.c:10)
+0x08048ac8: _start (lib/user/entry.c:9)
@end example
Here's an extra tip for anyone who read this far: @command{backtrace}
Example: @code{dumplist all_list thread all_elem} prints all elements of
@struct{thread} that are linked in @code{struct list all_list} using the
@code{struct list_elem all_elem} which is part of @struct{thread}.
+(This assumes that you have added @code{all_list} and @code{all_elem}
+yourself.)
@end deffn
@deffn {GDB Macro} btthread thread
Shows the backtrace of @var{thread}, which is a pointer to the
@struct{thread} of the thread whose backtrace it should show. For the
current thread, this is identical to the @code{bt} (backtrace) command.
-It also works for threads that are suspended in @func{schedule},
-provided you know where their kernel stack page is located.
+It also works for any thread suspended in @func{schedule},
+provided you know where its kernel stack page is located.
@end deffn
@deffn {GDB Macro} btthreadlist list element
all threads contained in @code{struct list all_list}, linked together by
@code{all_elem}. This command is useful to determine where your threads
are stuck when a deadlock occurs. Please see the example scenario below.
+(This assumes that you have added @code{all_list} and @code{all_elem}
+yourself.)
@end deffn
@deffn {GDB Macro} btpagefault
need to modify accordingly.
In Project 3, a page fault in a user process no longer automatically
-leads to the termination of a process. Rather, you may have to page in
-the page containing the address the process was trying to access, either
+leads to the termination of a process. Instead, it may require reading in
+data for the page the process was trying to access, either
because it was swapped out or because this is the first time it's
accessed. In either case, you will reach @func{page_fault} and need to
take the appropriate action there.
Project 3, the situation will change if you use @func{get_user} and
@func{put_user} strategy to verify user memory accesses
(@pxref{Accessing User Memory}).
+
+If you don't want GDB to stop for page faults, then issue the command
+@code{handle SIGSEGV nostop}. GDB will still print a message for
+every page fault, but it will not come back to a command prompt.
@end deffn
@node Example GDB Session
print out more debug information, such as the exact type of fault that
occurred. It's not very hard. You start by retrieving the source
code for Bochs 2.2.6 from @uref{http://bochs.sourceforge.net} and
-extracting it into a directory. Then read
-@file{pintos/src/misc/bochs-2.2.6.README} and apply the patches needed.
-Then run @file{./configure}, supplying the options you want (some
-suggestions are in the patch file). Finally, run @command{make}.
-This will compile Bochs and eventually produce a new binary
-@file{bochs}. To use your @file{bochs} binary with @command{pintos},
+saving the file @file{bochs-2.2.6.tar.gz} into a directory.
+The script @file{pintos/src/misc/bochs-2.2.6-build.sh}
+applies a number of patches contained in @file{pintos/src/misc}
+to the Bochs tree, then builds Bochs and installs it in a directory
+of your choice.
+Run this script without arguments to learn usage instructions.
+To use your @file{bochs} binary with @command{pintos},
put it in your @env{PATH}, and make sure that it is earlier than
-@file{/usr/class/cs140/`uname -m`/bochs}.
+@file{@value{localpintosbindir}/bochs}.
Of course, to get any good out of this you'll have to actually modify
Bochs. Instructions for doing this are firmly out of the scope of
@section Tips
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
+@file{threads/malloc.c} clear all the bytes in memory to
+@t{0xcc} at time of free. 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
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
+Breakpoint Exception)}, then Pintos tried to execute code in a freed page or
block.
An assertion failure on the expression @code{sec_no < d->capacity}
projects / pintos-anon / blobdiff