Function parameters passed in stack
by Durga Prasad
Hi,
I am going through the crash dump of a kernel module, and from the
disassembly, i find that the function parameters are passed in registers.
Is there a way I could 'discover' what those values were?
Thanks.
Durga Prasad
--
---------
Keep dreaming, for dreams are the precursors of things to come real.. @!#$
18 years
How to decode structs in the user area of memory
by Dheeraj Sangamkar
Hi,
When I debug ioctls, I get parameters which are pointers to structures in
user space.
I am unable to use the struct command to print these structures.
Currently I am using "rd -u" to read the content of user memory and decode
it based on the structure information I have.
Am I missing something? Is there any
18 years
user defined symbol
by Ming Zhang
Hi All
I wonder if it possible to have this feature - user defined symbol.
for example, define inode1 = 0x1234
then in all place has this 0x1234 in bt or rd command, show inode1
instead of numeric value,
This should be very helpful when these value pop up in a haystack of
numeric values...
Thanks
--
Ming Zhang
@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------
18 years
Unable to change the content of memory using crash on a live system
by Dheeraj Sangamkar
I use crash 4.0-3.9 on a live 2.6.9-55 kernel on i386/i686 as root.
crash> ls -l /dev/crash
crw------- 1 root root 10, 61 Mar 5 21:57 /dev/crash
crash> ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 Mar 5 16:49 /dev/mem
crash> q
[root@linux17081 ~]# ls -l /dev/crash /dev/mem
ls: /dev/crash: No such file or directory
crw-r----- 1 root kmem 1, 1 Mar 5 16:49 /dev/mem
[root@linux17081 ~]# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
So, the /dev/crash file has write permission for me. The
I am attempting to change the content of some memory.
crash> struct request_queue 0xf7b933f8
struct request_queue {
queue_head = {
<SNIP>
...
}
crash> struct -o request_queue | grep in_flight
[476] unsigned int in_flight;
crash> eval 0xf7b933f8 + 476
hexadecimal: f7b935d4
decimal: 4156110292 (-138857004)
octal: 36756232724
binary: 11110111101110010011010111010100
crash> rd f7b935d4
f7b935d4: fffffff1 ....
crash> wr f7b935d4 0
wr: cannot write to /dev/crash!
I get the error above even if I change the ownership of /dev/kmem to
root:root
crash> ls -l /dev/mem
crw-r----- 1 root root 1, 1 Mar 5 16:49 /dev/mem
Am I doing something wrong? How do I change the content of memory on a live
system using crash?
Dheeraj
18 years
Rodrigo Mateus Alves Matoani is out of the office.
by rmateus＠br.ibm.com
I will be out of the office starting 05/03/2008 and will not return until
01/04/2008.
I will respond to your message when I return.
Any problems on GAP please contact Brazil Unix 2nd Level(From US
916-630-8284 ext 7594) or Sergio Bueno (sergiob(a)br.ibm.com),
For another problem please contact Sabrina Almeida(sabrinat(a)br.ibm.com).
Thanks.
18 years
Re: [Crash-utility] Module debugging using crash
by Dave Anderson
Dheeraj Sangamkar wrote:
>
> Hi,
> Is there a way to print type information about types defined in a loadable
> kernel module? Is there a way to add to the type information that crash gets
> from the vmlinux file?
>
> This would ease debugging crashed module code be helping me print structures
> defined in modules.
>
> Dheeraj
Well, that's what the "mod" command does, i.e., load the debuginfo data
of kernel modules into the embedded gdb module of the crash session.
Take the "ext3" module for example. It declares this data structure in
the file "fs/ext3/super.c":
static struct super_operations ext3_sops = {
.alloc_inode = ext3_alloc_inode,
.destroy_inode = ext3_destroy_inode,
.read_inode = ext3_read_inode,
.write_inode = ext3_write_inode,
.dirty_inode = ext3_dirty_inode,
.delete_inode = ext3_delete_inode,
.put_super = ext3_put_super,
.write_super = ext3_write_super,
.sync_fs = ext3_sync_fs,
.write_super_lockfs = ext3_write_super_lockfs,
.unlockfs = ext3_unlockfs,
.statfs = ext3_statfs,
.remount_fs = ext3_remount,
.clear_inode = ext3_clear_inode,
.show_options = ext3_show_options,
#ifdef CONFIG_QUOTA
.quota_read = ext3_quota_read,
.quota_write = ext3_quota_write,
#endif
};
or for example, this data structure type is defined in
"fs/ext3/xattr.h":
struct ext3_xattr_header {
__le32 h_magic; /* magic number for identification */
__le32 h_refcount; /* reference count */
__le32 h_blocks; /* number of disk blocks used */
__le32 h_hash; /* hash value of all attributes */
__u32 h_reserved[4]; /* zero right now */
};
Without the ext3 module's debuginfo data, crash (and gdb) doesn't know
what they are, so if I try to print the "ext3_sops" symbolically,
this happens:
crash> p ext3_sops
p: gdb request failed: p ext3_sops
crash> whatis ext3_sops
whatis: gdb request failed: whatis ext3_sops
crash>
And if I want to see what an ext3_xattr_header structure is defined
as:
crash> struct ext3_xattr_header
struct: invalid data structure reference: ext3_xattr_header
crash>
But if the module's debuginfo data is loaded:
crash> mod -s ext3
MODULE NAME SIZE OBJECT FILE
e08c4f80 ext3 123337
/lib/modules/2.6.18-53.el5/kernel/fs/ext3/ext3.ko
crash>
(or use "mod -S" to load the debuginfo data of all modules),
then the same commands that failed above work like so:
crash> p ext3_sops
ext3_sops = $4 = {
alloc_inode = 0xe08b1c54 <ext3_alloc_inode>,
destroy_inode = 0xe08b2e4a <ext3_destroy_inode>,
read_inode = 0xe08ae0c9 <ext3_read_inode>,
dirty_inode = 0xe08ae063 <ext3_dirty_inode>,
write_inode = 0xe08ad696 <ext3_write_inode>,
put_inode = 0,
drop_inode = 0,
delete_inode = 0xe08ad7af <ext3_delete_inode>,
put_super = 0xe08b2f6d <ext3_put_super>,
write_super = 0xe08b1c37 <ext3_write_super>,
sync_fs = 0xe08b291d <ext3_sync_fs>,
write_super_lockfs = 0xe08b295f <ext3_write_super_lockfs>,
unlockfs = 0xe08b29ae <ext3_unlockfs>,
statfs = 0xe08b2c55 <ext3_statfs>,
remount_fs = 0xe08b2a21 <ext3_remount>,
clear_inode = 0xe08b2e5a <ext3_clear_inode>,
umount_begin = 0,
show_options = 0xe08b2835 <ext3_show_options>,
show_stats = 0,
quota_read = 0xe08b449b <ext3_quota_read>,
quota_write = 0xe08b45f5 <ext3_quota_write>
}
crash>
crash> ext3_xattr_header
struct ext3_xattr_header {
__le32 h_magic;
__le32 h_refcount;
__le32 h_blocks;
__le32 h_hash;
__u32 h_reserved[4];
}
SIZE: 32
crash>
The example above presumes the Red Hat split debuginfo module
format, where the "mod" command shows that the ext3 module
exists in:
/lib/modules/2.6.18-53.el5/kernel/fs/ext3/ext3.ko,
but that ext3.ko module contains a link to its associated debuginfo
part, which is actually located in:
/usr/lib/debug/lib/modules/2.6.18-53.el5/kernel/fs/ext3/ext3.ko.debug
If your module.ko file is not split into two, and has been built
with -g, then you can load its debuginfo data crash like so:
crash> mod -s yourmodule yourmodule.ko
Dave
18 years
enhance bt command
by Ming Zhang
Hi All
When use bt -f to show stack data, I need a quick way to find out what
are these stack data. For example, does any of these data are a inode
pointer, or ... So here is always what i do.
bt -f > stack
kmem -S inode_cache > inode
then use sort and comm utility to find value that appear in both files.
Is there a better way to do this?
I wish we can have a bt -f slab1 slab2...
and try to match the stack data with content from these slab cache
automatically.
Thanks!
--
Ming Zhang
@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------
18 years
Anyone seen this problem or what did i miss?
by Jay Lan
I tested in a rhel5.1 root with:
2.6.24 kernel
kexec-tools-testing-20080227
crash-4.0-5.1
Crash failed to initialize:
crash: read error: kernel virtual address: a0000001007f0868 type:
"kernel_config_data"
WARNING: cannot read kernel_config_data
crash: read error: kernel virtual address: a000000100f370b0 type: "xtime"
Has anyone else seen this problem?
Thanks,
- jay
18 years
Module debugging using crash
by Dheeraj Sangamkar
Hi,
Is there a way to print type information about types defined in a loadable
kernel module?
Is there a way to add to the type information that crash gets from the
vmlinux file?
This would ease debugging crashed module code be helping me print structures
defined in modules.
Dheeraj
18 years
