the backtrace.
Sometimes backtraces can be confusing without implying corruption.
-Compiler optimizations can cause surprising behavior. For example, 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.
+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
+function A calls another function B that never returns, the compiler may
+optimize such that an unrelated function C appears in the backtrace
+instead of A. Function C is simply the function that happens to be in
+memory just after A. In the threads project, this is commonly seen in
+backtraces for test failures; see @ref{The pass function fails, ,
+@func{pass} Fails}, for more information.
@menu
* Backtrace Example::
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 panicked.)
+(You will probably not see exactly the same addresses if you run the
+command above on your own kernel binary, because the source code you
+compiled and the compiler you used are probably different.)
The first line in the backtrace refers to @func{debug_panic}, the
function that implements kernel panics. Because backtraces commonly
are quite likely, and you should seriously consider both. We hope
that the third is less likely, but it is also possible.
+@menu
+* Debugging User Programs::
+@end menu
+
+@node Debugging User Programs
+@subsection Debugging User Programs
+
You can also use @command{gdb} to debug a user program running under
Pintos. Start by issuing this @command{gdb} command to load the
program's symbol table: