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