[Crash-utility] enhance bt command
Ming Zhang
blackmagic02881 at gmail.com
Mon Mar 3 21:23:43 UTC 2008
On Mon, 2008-03-03 at 16:16 -0500, Dave Anderson wrote:
> Ming Zhang wrote:
> > On Mon, 2008-03-03 at 15:35 -0500, Dave Anderson wrote:
> >
> > <snip>
> >
> >>>>> so we know the object address, which slab it is in, and the offset,
> >>>>> (thus can derive the raw value), all in one shot?
> >>>>>
> >>>> You've done a fine bit of debugging your issue...
> >>>>
> >>>> But I think that's a bit of overkill for each address reference.
> >>>>
> >>>> To do it right it would have to walk slab chains to gather all of the
> >>>> information needed by the "kmem -S" output, which can be extremely
> >>>> time-consuming, and potentially error-prone if the slab chain is
> >>>> corrupt or being modified while running on a live system.
> >>> full agree. realized now.
> >>>
> >>> then here is my question, how "kmem -s <addr>" find out which slab this
> >>> address belong to? by only looking at the page?
> >> The kmem_cache and containing slab addresses are stashed in unused
> >> fields of the page structure of the object's virtual address.
> >
> > ic. good to know this.
> >
> >
> >>> then here is my revised suggestion. can we split this into 2 steps?
> >>>
> >>> (1) rd -S show [raw address: cache name]
> >>>
> >>> (this is a great to have since do rd 2 times, one with -S and another
> >>> without -S is tedious.)
> >> But in your case, for example, I'm presuming you've done a "bt -f",
> >> and simply would like a symbols/slab translation of a chunk of memory
> >> making up one of the stack frames, so you do a subsequent "rd -S" of
> >> that memory area. Doesn't seem that tedious to me...
> >
> > have to agree.
> >
> >
> >>> (2) and kmem -s <address>
> >>>
> >>> show which slab it is in and optionally (with a new option like -O) show
> >>> the object?
> >> Not following -- "kmem -s <address>" does show which slab it's in.
> >
> > i emphasize on "and optionally...", ;)
> >
> >
> >> And if you're asking whether the object can be dumped as the structure
> >> type it is (?), well, how would it be possible from the crash utility's
> >> viewpoint to even know what type of data structure it is?
> >
> > no. what i mean is kmem -s <address> does not give me the object address
> >
> > crash> kmem -s 000001007877c8d4
> > CACHE NAME OBJSIZE ALLOCATED TOTAL
> > SLABS SSIZE
> > 10037ffc080 dentry_cache 240 9429 10560
> > 660 4k
> > SLAB MEMORY TOTAL ALLOCATED FREE
> > 1007877c040 1007877c088 16 9 7
> > FREE / [ALLOCATED]
> > [1007877c8d4]
> >
> >
> > i still have to use kmem -S to find out 1007877c808 is the object that
> > contain this address. nice if crash can do this for me.
>
> OK I understand. Yeah, it's always worked that way -- I don't recall
> why other than the fact that by the time the address is displayed, the
> function that does the display no longer has a handle on the beginning
> address of the object, only the "requested" address, the slab it came
> from, whether it's free/allocated, and whether it's sitting on a per-cpu
> cache. I'll have to revisit that sometime...
thanks for putting that on your todo list.
so will you check in the patch soon?
>
> >
> >
> >> If you want to look at all of the objects in a slab represented
> >> as data structures, you're going to have supply the knowledge of
> >> what data structure they are. It's simple enough, just do a "kmem -S"
> >> into a file, delete everything except the object addresses that you're
> >> interested in, insert "struct whatever" in front of each address, save
> >
> > this is exactly what i did when i have to do work like this by using
> > gawk, tr, and grep.
> >
> >> the file -- and run it as crash input file.
> >>
> >
> > how to do this? i know crash -i can run a file at beginning. but how to
> > run command in a file at any moment?
> >
>
> Enter "help input" -- where it talks about "<":
thanks for the hint. you save me quite a lot key strokes!
thanks again for all the help!
>
> crash> help input
> ...
> Lastly, a set of crash commands may be entered into a regular file that can
> used as input, again using standard command line syntax:
>
> crash> < inputfile
> ...
> crash>
>
> For example:
>
> crash> !cat /tmp/input
> bt
> sys
> set
> crash> < /tmp/input
> crash> bt
> PID: 1 TASK: c148eaa0 CPU: 1 COMMAND: "init"
> #0 [c148db04] schedule at c0604141
> #1 [c148db6c] schedule_timeout at c060487f
> #2 [c148db90] do_select at c04800b7
> #3 [c148de34] core_sys_select at c04803ba
> #4 [c148df74] sys_select at c0480981
> #5 [c148dfb8] system_call at c0404ef8
> EAX: 0000008e EBX: 0000000b ECX: bfc96b30 EDX: 00000000
> DS: 007b ESI: 00000000 ES: 007b EDI: bfc96c60
> SS: 007b ESP: bfc96afc EBP: bfc96df8
> CS: 0073 EIP: 00a4c402 ERR: 0000008e EFLAGS: 00000246
> crash> sys
> KERNEL: /usr/lib/debug/lib/modules/2.6.18-53.el5/vmlinux
> DUMPFILE: /dev/crash
> CPUS: 2
> DATE: Mon Mar 3 16:11:57 2008
> UPTIME: 20 days, 06:18:19
> LOAD AVERAGE: 0.00, 0.02, 0.05
> TASKS: 176
> NODENAME: crash.boston.redhat.com
> RELEASE: 2.6.18-53.el5
> VERSION: #1 SMP Wed Oct 10 16:34:02 EDT 2007
> MACHINE: i686 (1993 Mhz)
> MEMORY: 511.5 MB
> crash> set
> PID: 1
> COMMAND: "init"
> TASK: c148eaa0 [THREAD_INFO: c148d000]
> CPU: 1
> STATE: TASK_INTERRUPTIBLE
> crash>
>
> Dave
>
--
Ming Zhang
@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------
More information about the Crash-utility
mailing list