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 -------------------------------------------- -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
