From a76874e8d2ce82b9992bab669854aefa3b1224ea Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Wed, 8 Dec 2004 22:56:35 +0000 Subject: [PATCH] Talk more about backtraces. --- doc/debug.texi | 105 ++++++++++++++++++++++++++++++++++++++++++++++- doc/doc.texi | 4 +- doc/filesys.texi | 3 +- 3 files changed, 108 insertions(+), 4 deletions(-) diff --git a/doc/debug.texi b/doc/debug.texi index 7e372ca..35e7c4a 100644 --- a/doc/debug.texi +++ b/doc/debug.texi @@ -132,7 +132,7 @@ we've supplied a wrapper for it simply called @command{backtrace}. Give it the name of your @file{kernel.o} as the first argument and the hexadecimal numbers composing the backtrace (including the @samp{0x} prefixes) as the remaining arguments. It outputs the function name -and source file line numbers that correspond to each address. +and source file line numbers that correspond to each address. If the translated form of a backtrace is garbled, or doesn't make sense (e.g.@: function A is listed above function B, but B doesn't @@ -142,6 +142,109 @@ Alternatively, it could be that the @file{kernel.o} you passed to @command{backtrace} does not correspond to the kernel that produced the backtrace. +@menu +* Backtrace Example:: +@end menu + +@node Backtrace Example +@subsection Example + +Here's an example. Suppose that Pintos printed out this following call +stack, which is taken from an actual Pintos submission for the file +system project: + +@example +Call stack: 0xc0106eff 0xc01102fb 0xc010dc22 0xc010cf67 0xc0102319 +0xc010325a 0x804812c 0x8048a96 0x8048ac8. +@end example + +You would then invoke the @command{backtrace} utility like shown below, +cutting and pasting the backtrace information into the command line. +This assumes that @file{kernel.o} is in the current directory. You +would of course enter all of the following on a single shell command +line: + +@example +backtrace kernel.o 0xc0106eff 0xc01102fb 0xc010dc22 0xc010cf67 0xc0102319 +0xc010325a 0x804812c 0x8048a96 0x8048ac8 +@end example + +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) +@end example + +(You will probably not get the same results if you run the command above +on your own kernel binary, because the source code you compiled from is +different from the source code that emitted the panic message.) + +The first line in the backtrace refers to @func{debug_panic}, the +function that implements kernel panics. Because backtraces commonly +result from kernel panics, @func{debug_panic} will often be the first +function shown in a backtrace. + +The second line shows @func{file_seek} to be the function that panicked, +in this case as the result of an assertion failure. In the source code +tree used for this example, line 405 of @file{filesys/file.c} is the +assertion + +@example +ASSERT (file_ofs >= )0; +@end example + +@noindent +Thus, @func{file_seek} panicked because it passed a negative file offset +argument. + +The third line indicates that @func{seek} called @func{file_seek}, +presumably without validating the offset argument. In this submission, +@func{seek} implements the @code{seek} system call. + +The fourth line shows that @func{syscall_handler}, the system call +handler, invoked @func{seek}. + +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 +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): + +@example +~/cs140/pintos/src/utils/backtrace 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 (/home/blp/cs140/pintos/grading/filesys/grow-too-big.c:20) +0x8048a96: main (/home/blp/cs140/pintos/grading/filesys/fsmain.c:10) +0x8048ac8: _start (../../src/lib/user/entry.c:9) +@end example + @node i386-elf-gdb @section @command{i386-elf-gdb} diff --git a/doc/doc.texi b/doc/doc.texi index a2b8b7a..2fec1b4 100644 --- a/doc/doc.texi +++ b/doc/doc.texi @@ -118,11 +118,11 @@ Think about what the compiler might do to your code. Suppose you write the following to test your virtual memory implementation's ability to expand the stack: @example -int main (void) { +int main (void) @{ int array[4096]; array[123] = 234; return 0; -} +@} @end example @noindent The compiler is quite likely to notice that the value that you write to the array is never used again and thereby decide not to write diff --git a/doc/filesys.texi b/doc/filesys.texi index 36c21a3..ab97148 100644 --- a/doc/filesys.texi +++ b/doc/filesys.texi @@ -26,12 +26,13 @@ Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in @menu * File System New Code:: +* File System Synchronization:: * Problem 4-1 Large Files:: * Problem 4-2 File Growth:: * Problem 4-3 Subdirectories:: * Problem 4-4 Buffer Cache:: * File System Design Document Requirements:: -* File System FAQ:: +* File System FAQ:: @end menu @node File System New Code -- 2.30.2