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
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