Problem opening core file.
by Rohit Persai
Greetings,
I am trying to open a core file but getting following error. I am sure
that I am using right kernel + kernel-debuginfo package. As following
command on crash log shows version on kernel in use.
# cat crash-log | grep -i 2.4.21
EIP is at check_pgt_cache [kernel] 0x19 (2.4.21-47.ELsmp)
----------------------------------------snip-from-system-on-which-i-am-opening-core-file-----------------------------------------
# uname -r
2.4.21-47.ELsmp
# crash /usr/lib/debug/boot/vmlinux-2.4.21-47.ELsmp.debug
/boot/vmlinux-2.4.21-47.ELsmp case_1843132_vmcore
crash 4.0-6.3
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program 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. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
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"...
WARNING: invalid value: smp_num_cpus: -1070037996
crash: /usr/lib/debug/boot/vmlinux-2.4.21-47.ELsmp.debug and
case_1843132_vmcore do not match!
Usage:
crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist]
[dumpfile]
Enter "crash -h" for details.
----------------------------------------snip-from-system-on-which-i-am-opening-core-file-----------------------------------------
Question: Why am I getting following message if I am using right set of
packages.
crash: /usr/lib/debug/boot/vmlinux-2.4.21-47.ELsmp.debug and
case_1843132_vmcore do not match!
Any help would be greatly appreciated.
Rohit.
18 years
Re: [PATCH] crash: fix the bug about the command kmem
by anderson＠prospeed.net
>
> Hi
> When I use kmem command on an IA64 box with RHEL5.2 as following,
> there are some errors.
>
> crash> kmem -P e000000076c00000
> Segmentation fault
>
> The issue is that dump_mem_map() shouldn't be called when the address is a
> bad address.
>
> Signed-off-by: Wen Congyang <wency(a)cn.fujitsu.com>
>
> ---
> memory.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/memory.c b/memory.c
> index 912df04..f892391 100755
> --- a/memory.c
> +++ b/memory.c
> @@ -10379,7 +10379,11 @@ kmem_search(struct meminfo *mi)
> mem_map:
> mi->flags = orig_flags;
> pc->curcmd_flags &= ~HEADER_PRINTED;
> - dump_mem_map(mi);
> + if (vaddr != BADADDR) {
> + dump_mem_map(mi);
> + } else {
> + mi->retval = FALSE;
> + }
>
> if (!mi->retval)
> fprintf(fp, "%llx: %s address not found in mem map\n",
> --
> 1.5.3
>
>
>
>
> ------------------------------
Thanks for the patch -- I'll queue it for the next release.
It will be some time after August 4th -- I'm on vacation
and just happen to be borrowing somebody's laptop.
Dave Anderson (anderson(a)redhat.com)
18 years, 1 month
[PATCH] crash: fix the bug about the command kmem
by Wen Congyang
Hi
When I use kmem command on an IA64 box with RHEL5.2 as following,
there are some errors.
crash> kmem -P e000000076c00000
Segmentation fault
The issue is that dump_mem_map() shouldn't be called when the address is a bad address.
Signed-off-by: Wen Congyang <wency(a)cn.fujitsu.com>
---
memory.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/memory.c b/memory.c
index 912df04..f892391 100755
--- a/memory.c
+++ b/memory.c
@@ -10379,7 +10379,11 @@ kmem_search(struct meminfo *mi)
mem_map:
mi->flags = orig_flags;
pc->curcmd_flags &= ~HEADER_PRINTED;
- dump_mem_map(mi);
+ if (vaddr != BADADDR) {
+ dump_mem_map(mi);
+ } else {
+ mi->retval = FALSE;
+ }
if (!mi->retval)
fprintf(fp, "%llx: %s address not found in mem map\n",
--
1.5.3
18 years, 1 month
/dev/tty no such device or address
by SUJIT V
I am trying to invoke the crash utility through one of the linux startup
scripts.
crash -i command.txt vmlinux vmcore
But this gives an error
/dev/tty no such device or address.
The tty is /dev/console
Once the linux box boots up and i login and use the same crash command as
above it works correctly
The tty of the login shell is /dev/ttyS0
Any pointers on solving the error "/dev/tty no such device or address"
Thanks
18 years, 1 month
crash API?
by James Washer
I'm back with another wild question.
There are often times I'd like to use crash more as a library than a
utility. I've plaid with using "expect" routines, but find them rather
clumsy.
Has there ever been any discussion of a crash library or other API where
I might have the niceties of crash with a clean interface...
perhaps something along the lines of
crash=crash::open(kernel,dump)
crash->bt(pid)
crash->rd(address, length)
etc..
thanks
- jim
18 years, 1 month
Determining values of arguments and local variable in x86_64 crash dumps
by James Washer
I've always determined the values of locals and parameters/arguments the
hard way, i.e. by looking at the disassembly and determining where the
values are stored, etc.
I do note however that gdb is pretty damned good at "reading" variables
for user programs, which prompts me to ask.. why cannot we do this in
crash? (Perhaps we can and I'm just missing something)
Assuming that crash cannot locate locals/args, is there any chance crash
might (someday) determine where a register is spilled higher up the
stack frame?
Yes, I realize this is all wishlist stuff.. but it cannot hurt to ask
(can it?)
- jim
18 years, 1 month
