----- Original Message -----
> Hi,
> This is part of a stack backtrace of kernel
> 2.6.32-279.19.1.el6.x86_64,
> bt -f
> ...
> #7 [ffff880028283b38] dev_queue_xmit at ffffffff8142dac9
> ffff880028283b40: ffff880028283b80 ffffffff81445ffa
> ffff880028283b50: ffff8801175ef020 ffff880079551680
> ffff880028283b60: ffff880116a07480 000000000000000e
> ffff880028283b70: ffff880116a074c0 ffff88007a266c80
> ffff880028283b80: ffff880028283bd0 ffffffff81432b75
> #8 [ffff880028283b88] neigh_resolve_output at ffffffff81432b75
> ffff880028283b90: ffff880028283c10 ffffffff814547b4
> ffff880028283ba0: ffffffff81464e50 00000000000055b8
> ffff880028283bb0: ffff880037a7a800 000000000000000e
> ffff880028283bc0: ffff880079551680 ffff880037a7a858
> ffff880028283bd0: ffff880028283c10 ffffffff81464f8c
> ...
> crash> whatis dev_queue_xmit
> int dev_queue_xmit(struct sk_buff *);
>
> Take a look at #7, I know the value "ffffffff81432b75" is the return
> address, the saved RBP is ffff880028283bd0. What about the values
> between the address ffff880028283bd0 and address ffff880028283bd0?
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
Huh?
> Are they stack variables in function dev_queue_xmit? How can I
> distinguish compared the source code? Actually, I want to display
> the variables(including function parameters and local variables).
> Thanks.
The stack contents from ffff880028283b40 to ffff880028283b80
were used by dev_queue_xmit() prior to it calling whatever
function is in frame #6. The contents are either stack variables
and/or register-saves. Because the function parameters are
passed in registers, it's not obvious what, or where, they are
saved on the stack. It's possible that several functions may
be called with the same register argument, and that it was not
saved in the calling function. So with function parameters and
local variables, you'll have to disassemble the function up to
the point where it made the call to the next function, and figure
out what's what on the stack. (Use dis -rl <return-address>")
It's often helpful to use "bt -F" instead of "bt -f". If a stack
variable can be expressed symbolically, it will be, and if a
stack variable can be determined to be a slab cache object, the
slab cache name in brackets will be shown.
For example:
crash> bt -f
... [cut] ...
#4 [ffff81014d877ec0] sysfs_read_file at ffffffff8010bee9
ffff81014d877ec8: 0000000000001000 00000000078bb000
ffff81014d877ed8: ffffffff80323840 ffff81015ed59b80
ffff81014d877ee8: 0000000000001000 00000000078bb000
ffff81014d877ef8: ffff81014d877f50 0000000000001000
ffff81014d877f08: 0000000000000000 ffffffff8000bd48
...
crash> bt -F
... [cut[ ...
#4 [ffff81014d877ec0] sysfs_read_file at ffffffff8010bee9
ffff81014d877ec8: 0000000000001000 00000000078bb000
ffff81014d877ed8: class_device_attr_cpuaffinity [filp]
ffff81014d877ee8: 0000000000001000 00000000078bb000
ffff81014d877ef8: [sighand_cache] 0000000000001000
ffff81014d877f08: 0000000000000000 vfs_read+203
...
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
