crash bug on 2.6.27.8
by Jun Koi
Hi,
When using the latest crash on 2.6.27.14 to analyze live memory
(running crash without any option), I got a bug like below. How can I
fix that?
(A similar problem is also seen on 2.6.27.8)
Thanks,
Jun
.....
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
crash: read error: kernel virtual address: c0488200 type: "cpu_possible_map"
WARNING: cannot read cpu_possible_map
crash: read error: kernel virtual address: c041b428 type: "cpu_present_map"
WARNING: cannot read cpu_present_map
crash: read error: kernel virtual address: c041ab00 type: "cpu_online_map"
WARNING: cannot read cpu_online_map
crash: read error: kernel virtual address: c04b1900 type: "xtime"
15 years, 4 months
crash version 4.0-7.7 is available
by Dave Anderson
- Because the ia64 and ppc64 architectures have configurable page
sizes, a host system running a crash session against a dumpfile may
have a different page size than the system that generated the
dumpfile. If the dumpfile is a compressed kdump vmcore or a
diskdump vmcore, the page size will be reset to the dumpfile header's
block_size variable if it does not agree with the host system's page
size. If the dumpfile is a 64-bit kdump ELF vmcore with vmcoreinfo
data that includes the crashing system's page size, that page size
will be used if the architecture is an ia64 or ppc64.
(holt(a)sgi.com, bwalle.suse.de)
- Fix for "mod -[sS]" command if the target module object filename
contains both underscore and dash characters. Without the patch
the module load would fail with the error message: "mod: cannot
find or load object file for <name> module". Examples are
the "aes_x86_64" module from the "aes-x86_64.ko" object file, and
the "dm_region_hash" module from the "dm-region_hash.ko" object file.
(anderson(a)redhat.com)
- Reject s390 and s390x "L2^B" local label symbols from the kernel
symbol list. (bwalle(a)suse.de)
- Enlarge the string format buffer in the show_last_run() function to
prevent a buffer overflow when running "ps -l".
(sachinp(a)in.ibm.com)
- Fix for "bt -a" to continue with the backtraces of the remaining
active tasks when one of them encounters a fatal error. Without
the patch, the command is aborted when any of the backtraces fail.
(anderson(a)redhat.com)
- Only allow trusted versions of .crashrc and .gdbinit files to be
sourced during session initialization. (anderson(a)redhat.com)
- Fix for a potential but highly unlikely buffer overflow in the gdb
dwarfread.c and dwarf2read.c files, which requires a hand-crafted
object file with a location block (DW_FORM_block) that contains a
large number of operations. (anderson(a)redhat.com)
- Fix for a potential but highly unlikely integer overflow in the
Binary File Descriptor (BFD) library, which requires a hand-crafted
object file that that specifies a large number of section headers,
leading to a heap-based buffer overflow. (anderson(a)redhat.com)
- Enable stack unwind on ia64 when using a kerntypes file as the
kernel namelist. (cpw(a)sgi.com)
- Fix for failure of "files -R" command option if an inode is unknown
due to a NULL f_dentry pointer in any open file structure because of
a kernel error condition. Without the patch, the command aborts
prematurely with the error message: "files: invalid input: ?".
(anderson(a)redhat.com)
- Allow an LKCD kerntypes debuginfo file created from a kernel module
to be loaded with the command: "mod -s <module> <kerntypes-file>".
(cpw(a)sgi.com)
- Increased NR_CPUS from 256 to 512 for x86_64, and from 128 to 1024
for ppc64. Made several NR_CPUS-bound static arrays in the internal
task_table and kernel_table structures dynamically allocated only
upon demand. (anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
15 years, 4 months
Ramin SHARIATIAN est absent(e).
by ramin.shariatian＠ineo.com
Je serai absent(e) à partir du 02/02/2009 de retour le 09/02/2009.
Je répondrai à votre message dès mon retour.
15 years, 5 months
Re: bt -f (ia64)
by Dave Anderson
----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
> On Fri, Jan 30, 2009 at 03:36:00PM -0500, Dave Anderson wrote:
> >
> > ----- "Cliff Wickman" <cpw(a)sgi.com> wrote:
> > > Hi Dave,
> > >
> > > In using crash yesterday on an ia64 dump I found that "bt -f" did
> > > not show contents of the stack. Neither memory stack nor stacked
> registers.
> > > (It does show the "bsp" pointer to backing storage, which helps)
> > >
> > > It must have displayed the stacks' contents in the past, as the help for
> > > bt says:
> > > -f display all stack data contained in a frame; this option can be
> > > used to determine the arguments passed to each function; on ia64,
> > > the argument register contents are dumped.
> > >
> > > I don't find any discussion on this subject.
> > > Can you tell me anything about the status of it?
> >
> > As the help page states, the ia64 "bt -f" option dumps the arguments
> > to each function. On the other architectures, it dumps the data in
> > each stack frame as an aid in finding the function arguments.
> >
> > If you want to look at raw ia64 stack contents, use "bt -r".
>
> bt -r shows the memory stack, but not per-function.
> And to see function arguments we need the register stack.
> BSP is the address of register stack backing storage, but it would be
> nice if -f broke out both the register and memory stack frames.
>
> crash> bt -f e00000b8740a0000
> PID: 32111 TASK: e00000b8740a0000 CPU: 4 COMMAND: "bash"
> #0 [BSP:e00000b8740a1458] schedule at a0000001006e4170
> #1 [BSP:e00000b8740a13a8] do_wait at a0000001000a2e50
> #2 [BSP:e00000b8740a1330] sys_wait4 at a0000001000a3590
> #3 [BSP:e00000b8740a1330] ia64_ret_from_syscall at a00000010000c600
> EFRAME: e00000b8740afe40
> ...
I don't know why you don't see per-function arguments:
crash> bt -f e0000003e0038000
PID: 10464 TASK: e0000003e0038000 CPU: 0 COMMAND: "bash"
#0 [BSP:e0000003e00393c0] schedule at a00000010064a130
(void)
#1 [BSP:e0000003e0039350] do_wait at a000000100083af0
(ffffffffffffffff, e, 0, 60000fffffcc780c, 0)
#2 [BSP:e0000003e00392f8] sys_wait4 at a000000100084000
(ffffffffffffffff, 60000fffffcc780c, a, 0)
#3 [BSP:e0000003e00392f8] __ia64_trace_syscall at a00000010000bdd0
EFRAME: e0000003e003fe40
...
>
>
> Something like this:
> >> trace -f 0xe00000b433c00000
> ================================================================
> STACK TRACE FOR TASK: 0xe00000b433c00000 (bash)
>
> 0 schedule+0x10ac [0xa0000001006e416c]
>
> RA=0xa0000001000a2e50, PFS=0xa9d, CFM=0x8
> SP=0xe00000b433c0fdf0, MSIZE=0
> BSP=0xe00000b433c01458, BSIZE=0
>
> 1 do_wait+0x44c [0xa0000001000a2e4c]
>
> RA=0xa0000001000a3590, PFS=0x795, CFM=0xa9d
> SP=0xe00000b433c0fdf0, MSIZE=8
> BSP=0xe00000b433c013a8, BSIZE=21
>
> REGISTER FRAME:
>
> 32: 0x6000000007bb7a88 33: 0x000000000001b789
> 34: 0x0000000000000001 35: 0x0000000000000006
> 36: 0x000000000001b789 37: 0x0000000000000098
> 38: 0x0000000000000000 39: 0x0000000000000000
> 40: 0x0000000000000000 41: 0x0000000000000000
> rnat: 0x0000000000000000 42: 0x0000000000000000
> 43: 0x0000000000000000 44: 0x0000000000000000
> 45: 0x0000000000000000 46: 0x6000000007bb7ad8
> 47: 0x0000000000000000 48: 0x6000000007bb6138
> 49: 0x0000000000000051 50: 0x6000000007bb7a50
> 51: 0x6000000007bb7a50
>
> MEMORY FRAME:
>
> e00000b433c0fdf0: e00000b433c01680 089aa0aaaa5a9669
> e00000b433c0fe00: 600fffffffd6e7ec 0000000000000000
> e00000b433c0fe10: 00000000fffffe00 0000000000000000
> e00000b433c0fe20: e00000b433c00000 a0000001008f3450
>
> 2 sys_wait4+0x12c [0xa0000001000a358c]
>
> Didn't the "old" ia64 unwind do something like that?
Never. The ia64 backtrace code is port of the kernel unwind
code into user space.
Dave
15 years, 5 months
