[Crash-utility] [ANNOUNCE] crash version 5.0.9 is available

[Dave Anderson]

changelog:

 - Make the symbol_search_next() function externally available to
   extension modules, as requested for the "pykdump" extension module. 
   (anderson at redhat.com)

 - Fix for the "log" command to recognize that the "log_end" symbol
   was changed from an unsigned long to an unsigned int in 2.6.25 and 
   later kernels.
   (anderson at redhat.com)

 - Fix to determine the size and location of the x86_64 interrupt stack
   on kernels that are not configured CONFIG_SMP.  Without the patch, 
   runtime commands that use the embedded gdb module may fail with the
   error message "<segmentation violation in gdb>".
   (anderson at redhat.com)

 - Suppress the "crash -d1" initialization-time message that indicates 
   "WARNING: Because this kernel was compiled with gcc version <x.x.x>, 
   certain commands or command options may fail unless crash is invoked 
   with the --readnow command line option" to only be displayed with 
   kernels compiled with gcc versions between 3.4.0 and 4.0.0.
   (anderson at redhat.com)

 - Fix for the "bt" command on 2.6.33 and later x86_64 kernels, which
   contain debuginfo data for "struct user_regs_struct", and where the
   the dumpfile is a kdump ELF vmcore.  Without the patch, the backtrace 
   for the panic task uses the registers found in the ELF header's 
   NT_PRSTATUS note as starting hooks, which causes the backtrace to be 
   essentially truncated, leaving out the exception frame, the exception
   handler's frame, and so on, down to the kdump operation.  The patch
   will only use the ELF header's registers if better starting hooks 
   cannot be determined.
   (anderson at redhat.com)
 
 - Fix for handling KVM dumpfiles that contain "devices" that are not
   explicitly supported.  The patch skips over the unsupported/unused
   device segment in the dumpfile, and searches for the next "known"
   device contained in the supported device table.  Without the patch,
   the crash session fails during initialization with the error message
   "crash: <dumpfile>: initialization failed".
   (anderson at redhat.com)
     
 - When handcrafting the backtrace starting point for the "bt" command
   by using the -S option, and the starting stack address is not in
   the task's process stack or in a legitimate non-process stack 
   address, such as a hard or soft IRQ stack address, or an x86_64 
   exception stack address, a message gets displayed that indicates
   "non-process stack address for this task".  Without the patch, the
   backtrace is still attempted, which may result in a segmentation
   violation, so this behavior has been changed such that the "bt"
   command will fail immediately.    
   (anderson at redhat.com)

 - Modified the help page for the "help" command to also show the
   various crash-internal debug options available.
   (anderson at redhat.com)

 - Fix for the x86_64 "bt" command to more correctly find the starting
   backtrace RIP and RSP hooks in KVM dumpfiles.  Without the patch,
   backtraces that should start in the interrupt or exception stacks
   were not being detected correctly.
   (anderson at redhat.com)

 - Save the per-cpu register contents stored in the "cpu" devices of 
   x86_64 KVM dumpfiles, and use their contents for x86_64 backtrace RSP
   and RIP hooks in the case of KVM "live dumps" where the guest system 
   was not in a crashed state when the "virsh dump" operation was done
   on the KVM host.  If an active task was running in user space when 
   a live dump was taken, that will be indicated by the "bt" output, 
   along with the user-space register contents.  The x86_64 register set 
   saved for each cpu may be displayed with the "help -[D|n]" command.
   (hutao at cn.fujitsu.com, anderson at redhat.com)

 - Fix for the cpu count determination in crashed x86 KVM dumpfiles, 
   where the non-crashing cpus are marked offline in the kernel's
   cpu_online_mask by smp_stop_cpu().  Depending upon the cpu number
   of the crashing task, the cpu count may be set to a value that is
   less than the number of present cpus.
   (anderson at redhat.com)
 
 - Fix for a premature failure of the "kmem -i" command with kernels 
   that are not configured with CONFIG_SWAP.
   (per.xx.fransson at stericsson.com)

 - Fix for the x86 "bt" command on 2.6.31 and later kernels when the
   crash was generated by an "echo c > /proc/sysrq-trigger".  Without
   the patch, the backtrace does not display the exception frame from
   the forced oops.  This is not applicable to older kernels where 
   crash_kexec() is called directly from sysrq_handle_crash(), or if 
   an actual alt-sysrq-c keystroke sequence is entered.
   (anderson at redhat.com)

 - Fix for the x86 "bt" command to correctly find the starting backtrace
   EIP and ESP hooks for the active tasks in KVM dumpfiles where the 
   kernel had crashed.
   (anderson at redhat.com)

 - Fix to utilize the correct "cpu" device format in x86 KVM dumpfiles
   Without the patch, the x86 registers were read in a 32-bit format, 
   which is only true if the host machine was running a 32-bit kernel.
   With the patch, the format defaults to the 64-bit format, and is
   switched to the 32-bit format if it can be determined that the host
   machine was running a 32-bit kernel.
   (hutao at cn.fujitsu.com, anderson at redhat.com)

 - Save the per-cpu register contents stored in the "cpu" devices of
   x86 KVM dumpfiles, and use their contents for x86 backtrace ESP and
   EIP hooks in the case of KVM "live dumps", i.e., where the guest
   system was not in a crashed state when the "virsh dump" operation
   was done on the KVM host.  If an active task was running in user
   space when a live dump was taken, that will be indicated by the
   "bt" output, along with the user-space register contents.  The saved
   x86 register set for each cpu may also be displayed with the
   "help -[D|n]" command.
   (hutao at cn.fujitsu.com, anderson at redhat.com)

 - Update for the KVM-only "map" command to also store the register sets
   read from the the KVM dumpfile's "cpu" devices in addition to the 
   mapfile data when it is written to an external mapfile, or appended 
   to the dumpfile, so that subsequent sessions will not require the 
   initial scan of the KVM dumpfile.
   (anderson at redhat.com)

 - Fix the KVM-only "map" command to prevent its use when the session
   is not being run against a KVM dumpfile, and to reject filename
   arguments to the -a option or without the -f option.
   (anderson at redhat.com)

 Download from: http://people.redhat.com/anderson