Re: JWW SPAM-bad-from enhance bt command

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-utilityredhat.com
https://www.redhat.com/mailman/listinfo/crash-utility