The bt command displays a task's kernel-stack backtrace. When running this command against an x86 Xen kernel vmcore, crash did not correctly handle the transition from the IRQ stack back to the process stack, leading to a segmentation fault. The version of crash provided with this advisory contains a patch that corrects this issue, allowing users to analyze a vmcore file from a system with an x86 Xen kernel.

if entered alone on the command line, the "set" command would cause a segmentation violation, because there is no concept of a "context" in the Xen hypervisor. Crash now prompts the user to provide an option with "set", and provides more meaningful error messages if the option selected is not applicable. (BZ#462819)

crash would indicate "irq: invalid structure size: gate_struct" and dump a stack trace leading to x86_64_display_idt_table() when the "irq -d" option was run on AMD64 and Intel 64 Xen kernels. Now it will indicate that the -d option is not applicable. (BZ#464116)

the "bt" command did not work correctly when running against the Xen hypervisor binary. The "bt -o" option, and setting it to run by default with "bt -O", would fail with the vmlinux-specific error message "bt: invalid structure size: desc_struct" with a stack trace leading to read_idt_table(). Now, it will display the generic error message "bt: -o option not supported or applicable on this architecture or kernel". The "bt -e" or "bt -E" will also display the same error message, as opposed to the command usage message. Lastly, the "bt -R" option would cause a segmentation violation; it has been fixed to work as it was designed. (BZ#464288)

when run on a Xen hypervisor in which the backtrace leads to either "process_softirqs" or "page_fault", the "bt" command backtrace would indicate: "bt: cannot resolve stack trace". The recovery code would then terminate the command with the nonsensical error message: "bt: invalid structure size: task_struct". The command now properly terminates the backtrace. (BZ#474712 , BZ#466724)

when run against the Xen hypervisor where the number of physical cpus outnumber the MAX_VIRT_CPUS value for the processor type, the "bt -a" command would fail after displaying backtraces for the first 32 (MAX_VIRT_CPUS) pcpus with the the error message: "bt: invalid vcpu". The command now shows backtraces for all pcpus. (BZ#471790)

the "mod -[sS]" command would fail with the error message: "mod: cannot find or load object file for <name> module" if the target module object filename contains both underscore and dash characters. Crash now parses these filenames correctly. (BZ#480136)

an existing Itanium INIT and MCA handler bug incorrectly writes the pseudo task's command name in its comm[] name string such that the CPU number may not be part of the string. The "bt" command could not link back to a PID 0 swapper task that was interrupted by an Itanium INIT or MCA exception, and displayed the error message: "bt: unwind: failed to locate return link (ip=0x0)!" Crash now uses a different method to obtain the CPU number for the interrupted task, and the backtrace correctly transitions back to the interrupted task. (BZ#487429)

the starting backtrace location of active, non-crashing, xen dom0 tasks are not available in kdump dumpfiles, nor is there anything that can be searched for in their respective stacks. Therefore, for these tasks, the "bt" command would show either an empty backtrace or an invalid backtrace starting at the last location where schedule() had been called. Instead, the "bt" command now provides an error message for these tasks that indicated "bt: starting backtrace locations of the active (non-crashing) xen tasks cannot be determined: try -t or -T options". (BZ#495586)

Running the "bt" command against an x86 Xen kernel vmcore, the transition from the IRQ stack back to the process stack led to a segmentation fault. (BZ#478904)