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

[Ming Zhang]

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.



> 
>  - 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
--------------------------------------------