|
Size: 1296
Comment: converted to 1.6 markup
|
Size: 1374
Comment: and rename of UNWINDER_FRAME_POINTER
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| This is a normal occurance in Linux. Unless `CONFIG_FRAME_POINTER` is enabled, the function `print_context_stack()` simply walks the whole stack and looks for any value that might be the address of a function in the kernel. It has no way of knowing whether that address is a stack frame return address from the current code path, a left-over return address from a previous code path or just a random value that was left on the stack. | This is a normal occurence in Linux. Unless `CONFIG_FRAME_POINTER` (or later, `CONFIG_UNWINDER_FRAME_POINTER` is enabled, the function `print_context_stack()` simply walks the whole stack and looks for any value that might be the address of a function in the kernel. It has no way of knowing whether that address is a stack frame return address from the current code path, a left-over return address from a previous code path or just a random value that was left on the stack. |
| Line 7: | Line 7: |
| If you want to always get reliable stack traces when an oops happens, make sure you enable `CONFIG_FRAME_POINTER`, as well as `CONFIG_STACKTRACE`, `CONFIG_UNWIND_INFO` and `CONFIG_STACK_UNWIND`. | If you want to always get reliable stack traces when an oops happens, make sure you enable `CONFIG_FRAME_POINTER` or `CONFIG_UNWINDER_FRAME_POINTER`, as well as `CONFIG_STACKTRACE`, `CONFIG_UNWIND_INFO` and `CONFIG_STACK_UNWIND`. |
Why does my backtrace contain a mixture of function call chains?
So your kernel oopsed and gave you a stack trace that mostly makes sense, but has a function or two on it that do not get called at all in this code path?
This is a normal occurence in Linux. Unless CONFIG_FRAME_POINTER (or later, CONFIG_UNWINDER_FRAME_POINTER is enabled, the function print_context_stack() simply walks the whole stack and looks for any value that might be the address of a function in the kernel. It has no way of knowing whether that address is a stack frame return address from the current code path, a left-over return address from a previous code path or just a random value that was left on the stack.
If you want to always get reliable stack traces when an oops happens, make sure you enable CONFIG_FRAME_POINTER or CONFIG_UNWINDER_FRAME_POINTER, as well as CONFIG_STACKTRACE, CONFIG_UNWIND_INFO and CONFIG_STACK_UNWIND.
With these configuration options switched on, the kernel knows exactly which addresses are part of the current call chain, and which are not.
How do I manually get a stack trace?
You can manually try to create the stack trace from an oops message or from the stack dump of a task. See the ABI page for details on the stack convention for your architecture.