Ming Zhang wrote:
On Sat, 2008-03-01 at 17:15 -0800, James Washer wrote:
I think you'll have better luck consulting the source code, and
disassembly to figure out what is on the stack.
checking asm code and finding out what is on the stack is sure the most
accurate way. but a hint could speed up the process.
For the example you've cited, if a given function uses an inode pointer,
it shouldn't take but a minute or so to determine where in the stack
frame this inode is located. (unless of course it turns out to be in a
register only, in which case you have to look for it to be spilled in a
subsequent frame)
quite some time you can see from the asm code that a important parameter
is stored in register and you have to go several level deeper before
finding it. so a hint which quickly locate a potential 'hot' data and
later revalidate with code reading is still very appealing.
I'm not sure whether cluttering the bt -f command output would
be all that worthwhile, but I'm thinking that this request may have
some merit with respect to the "rd" command. Currently the
"rd -s" option recognizes and translates kernel symbols that it
finds in the raw memory output. Maybe something like a "-S"
option could do that -- plus also recognize kernel virtual memory
addresses that come from the slab cache, and alternatively display
the slab cache namestring in some recognizable manner, i.e. bracketed,
or something like to that effect.
Then since "bt -f" displays the block of memory associated with
each stack frame, you could easily transfer the stack address
to a "rd -S [stack-address] [count]" command.
Dave
- jim
On Sat, 2008-03-01 at 17:38 -0500, Ming Zhang wrote:
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!
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
