JWW SPAM-bad-from [Crash-utility] enhance bt command

[Ming Zhang]

On Mon, 2008-03-03 at 09:19 -0500, Dave Anderson wrote:
> 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.

yes. it will be great if we can have a rd -S!


> 
> 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!
> >>>
> >>>
> 
-- 
Ming Zhang


@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------