----- "Dheeraj Sangamkar" <dheerajrs(a)gmail.com> wrote:
Hi,
I am able to use crash to debug a crash dump generated when I initiate
the crash using the sysrq-trigger in the /proc directory.
But when I try to use crash to debug a kernel vmcore generated due to
the insertion of my module, I get the error below.
Please let me know if I am doing anything wrong or if you think that
the dump is corrupted. I use kdump for dump collection.
I am using a 2.6.27.4-2-default kernel.
---------------------------------------------------------------------------------------------------------------------------------
/var/crash/2008-12-01-18:40 # crash System.map-default vmlinux vmcore
If the vmlinux file is the same kernel as is running on your live system,
then do not use the "System-map-default" file. If you're not sure, then
just run "crash vmlinux vmcore", and if the vmlinux file does not match
you will get an error message.
That being said, it's highly unlikely that it is the problem at hand -- but
please avoid using System.map files if at all possible.
crash 4.0-7.4
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 "x86_64-unknown-linux-gnu"...
please wait... (gathering module symbol data) buf_1K_used: 299
buf_2K_used: 1
buf_4K_used: 155
buf_8K_used: 1
buf_32K_used: 2
buf_1K_ovf: 0
buf_2K_ovf: 0
buf_4K_ovf: 0
buf_8K_ovf: 0
buf_32K_ovf: 0
buf_1K_maxuse: 2 of 10
buf_2K_maxuse: 1 of 10
buf_4K_maxuse: 1 of 5
buf_8K_maxuse: 1 of 5
buf_32K_maxuse: 1 of 1
buf_inuse[5]: [0][0][0][0][1]
smallest: 16
largest: 21474854400 <=== allocation of this buffer size failed
embedded: 2
max_embedded: 2
mallocs: 0
frees: 0
reqs/total: 459/21475603516.0
average size: 46787807.2
crash: cannot allocate any more memory!
While gathering the symbols of the currently-loaded kernel modules,
something has caused crash to attempt a bizarre memory allocation of
21474854400 (20GB+), which dutifully failed.
Most likely something has changed in the struct module that has caused
crash to go off into the weeds. It may very well be fixed in a currently-
queued patch that Bernhard Walle sent in:
[Crash-utility] [PATCH] Fix module size and num_symtab for 2.6.27
https://www.redhat.com/archives/crash-utility/2008-November/msg00000.html
Try applying that patch to 4.0-7.4 and see what happens.
Dave