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 -------------------------------------------- -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
