- Versioning has been changed such that the crash-<version>.tar.gz file no longer contains a "-" in the <version> number, and the crash-<version>-0.src.rpm will always have a crash.spec release number of "0". When the crash binary is built from the src.rpm file, the "-0" will not be included/displayed as part of the crash binary's version number, so that it will match the crash binary version that is built from the crash-<version>.tar.gz file. This is being done so that distributors can take the crash-<version>.tar.gz file and append their own crash.spec file release numbering scheme onto the base <version> number when creating their own src.rpm package. (anderson@xxxxxxxxxx) - Wholesale replacement of the x86/x86_64 disassembly code in the embedded gdb-6.1 module to that used in gdb-6.8. The primary motive is for CONFIG_FUNCTION_TRACER kernels, which contain a 5-byte nopl instructions that can be overwritten during runtime for dynamic ftracing. That particular nop format was not recognized by the older disassembly code in gdb-6.1, and printed a "(bad)" instruction followed by a incorrect "add" instruction. For example, without the patch, the instructions at sys_write+11 and sys_write+13 below are not correct: crash> dis sys_write 0xffffffff8113c56b <sys_write>: push %rbp 0xffffffff8113c56c <sys_write+1>: mov %rsp,%rbp 0xffffffff8113c56f <sys_write+4>: push %r12 0xffffffff8113c571 <sys_write+6>: push %rbx 0xffffffff8113c572 <sys_write+7>: sub $0x30,%rsp 0xffffffff8113c576 <sys_write+11>: (bad) 0xffffffff8113c578 <sys_write+13>: add %r8b,(%rax) 0xffffffff8113c57b <sys_write+16>: mov %rsi,%r12 ... With the patch, the 5-byte instruction is properly translated: crash> dis sys_write 0xffffffff8113c56b <sys_write>: push %rbp 0xffffffff8113c56c <sys_write+1>: mov %rsp,%rbp 0xffffffff8113c56f <sys_write+4>: push %r12 0xffffffff8113c571 <sys_write+6>: push %rbx 0xffffffff8113c572 <sys_write+7>: sub $0x30,%rsp 0xffffffff8113c576 <sys_write+11>: nopl 0x0(%rax,%rax,1) 0xffffffff8113c57b <sys_write+16>: mov %rsi,%r12 ... There are other side-effects/changes such as the output of negative relative offsets from registers. For example, without the patch, instructions like this: mov 0xffffffffffffffc8(%rbp),%rdx are displayed in an easier-to-understand format: mov -0x38(%rbp),%rdx There are undoubtedly other subtle changes as well. (anderson@xxxxxxxxxx) - Fix for compressed diskdump/kdump vmcores to properly handle page descriptor structures that are located beyond a 4GB file offset in the vmcore file. (oomichi@xxxxxxxxxxxxxxxxx) - Fix for x86_64 "bt" command to properly recognize vsyscall FIXMAP virtual addresses when encountered as the RIP in an exception frame. Without the patch, the exception frame would be followed by the warning message: "bt: WARNING: possibly bogus exception frame". (anderson@xxxxxxxxxx) - Fix for the "sym <address>" command option when the address references a symbol in the vsyscall FIXMAP virtual address page in certain x86_64 kernel versions. Without the patch, the command would fail with a "symbol not found" message. This would also affect commands that perform symbolic translations of virtual addresses, such as "rd -s". (anderson@xxxxxxxxxx) - Fix for the x86_64 "bt" command that may possibly start the backtrace of an active non-crashing task on its per-cpu IRQ stack instead of starting from the NMI exception stack. This could only occur on a kdump-generated vmcore, and as a result, the backtrace would make a faulty transition back to the process stack, dump a bogus exception frame, and display: "bt: WARNING: possibly bogus exception frame". (anderson@xxxxxxxxxx) - Fix for the x86_64 "bt" command in determining the frame just above an IRQ interrupt exception frame, or above an exception frame that gets handled on the process stack, such as a page fault. Without the patch, the frame size of the interrupted function was being incorrectly calculated, and could result in the display of an invalid stale frame just above the exception frame register dump. (anderson@xxxxxxxxxx) - Fix for the x86_64 "bt" command's frame size calculating mechanism to differentiate between text return addresses and the precise text RIP address of an exception. Without the patch, the instruction of the text return address location was being incorrectly scanned for instructions that modify the frame size, and could result in the skipping of a stack frame. (anderson@xxxxxxxxxx) - Fix for usage of a System.map file argument with 2.6.30 and later kernels (which only should be done if the vmlinux file does not match the vmcore or live system being analyzed). Without the patch there may be several hundred "crash: symbol count overflow (trace_kmalloc)" messages displayed during the back-patching of the gdb minimal_symbol table phase. (anderson@xxxxxxxxxx) - Fix for usage of a System.map file argument whose symbol list does not contain an "_end" symbol. Without the patch, the crash session fails during initialization with the error message: "crash: cannot resolve _end". (anderson@xxxxxxxxxx) - Fix for "kmem -p <address>" or "kmem <address>" options when the <address> is not a page structure address. Without the patch, starting with crash version 4.0-8.11, harmless but annoying "kmem: WARNING: sparsemem: invalid section number: 8192" messages would be displayed as a result of this patch. (anderson@xxxxxxxxxx) - Fix for the snap.so extension module when run on pre-2.6.13 x86_64 kernels with more than 4GB of physical memory. Without the patch, the resultant vmcore would not include memory above 4GB because the /proc/iomem file did not display it. A typical crash session would fail during initialization with an error message such as "crash: read error: kernel virtual address: 1020009d024 type: tss_struct ist array". (anderson@xxxxxxxxxx) - Fix for the build of the sial.so extension module if /usr/bin/bison and /usr/bin/flex do not exist on the host build system. When those files do not exist, the build of sial.so generates a huge number of error messages, ending with "make[3]: [sial.so] Error 1 (ignored)". Since it is preferable to avoid extra BuildRequires entries in the crash.spec file for extension modules, and given that it is often built from a tar.gz installation, the failed build will indicate: "sial.so: build failed: requires /usr/bin/flex and /usr/bin/bison". (anderson@xxxxxxxxxx) - Fix for the build of the snap.so extension module on older systems running with "make" versions 3.80 or earlier. Without the patch, the build of snap.so would fail like so: snap.mk:4: Extraneous text after `else' directive snap.mk:7: Extraneous text after `else' directive snap.mk:7: *** only one `else' per conditional. Stop. make[2]: [snap.so] Error 2 (ignored) The snap.mk file has been modified to conform to the older format. (anderson@xxxxxxxxxx) - Fix for the "rd" and "vtop" commands on RHEL4 x86_64 Xen paravirtual kernels in the reading or translation of vmalloc addresses that are not in kernel module vmalloc address space. In that kernel version (and none other that I am aware of), the PAGE_OFFSET unity-map kernel virtual address of 0xffffff8000000000 is larger than the address of its VMALLOC_START, 0xffffff0000000000. Because of that, without the patch, "rd" would fail with the error message "rd: invalid user virtual address: <address> type: 64-bit UVADDR", "vtop" would fail with the error message "vtop: ambiguous address: <address> (requires -u or -k)", and "vtop -k" would incorrectly report that the <address> was "(not a kernel virtual address)". (anderson@xxxxxxxxxx) - Implemented a new "-x" command line option that will automatically load extension modules from a particular directory. The search for the extension module directory will be done in the following order, and the first one (if any) that exists will be selected as the target directory: 1. the directory specified in the CRASH_EXTENSIONS shell environment variable 2. /usr/lib64/crash/extensions (64-bit architectures) 3. /usr/lib/crash/extensions 4. ./extensions All extension modules that are found in the target directory will be loaded automatically. (anderson@xxxxxxxxxx) Download from: http://people.redhat.com/anderson -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility