From: Bharata B R. <bh...@in...> - 2002-06-06 07:34:17
|
Here is one more approach for user space analysis using lcrash :-) While the 2 previous approaches generate a core file to be used by gdb, our approach is to do preliminary analysis of the task using just lcrash. With this, some initial investigation can be done to identify suspected tasks and perform a quick analysis in an overall system context. Thereafter if needed a more comprehensive analysis can be done by generating the core for the problem task(s). Currently our approach provides the following facilities 1. User memory view (currently, only non-swap memory, but should be possible to use the available swap dumping schemes to view the entire task memory) 2. Task symbol resolution, including the shared object symbols (symbol map files should be provided via symtab command) 3. User space backtrace (only if symbol info is available) 4. User data structures dump (if kerntypes info is available) 5. User code disassembly, including library code. Here is an example of how the backtrace of a task looks in the overall sytem context. ================================================================ STACK TRACE FOR TASK: 0xc2ae6000(test3) 0 schedule+726 [0xc010f026] 1 schedule_timeout+121 [0xc010ed09] 2 sys_nanosleep+265 [0xc0118ab9] 3 system_call+44 [0xc0106cec] ebx: bffff8f8 ecx: bffff8f8 edx: 40145bc0 esi: bffff8f8 edi: 00010000 ebp: bffffaa8 eax: 000000a2 ds: 002b es: 002b eip: 400d4a61 cs: 0023 eflags: 00000286 esp: bffff8dc ss: 002b USER STACK TRACE: 4 __nanosleep+17 [0x400d4a61] 5 func+14 [0x804849e] 6 main+52 [0x80484e4] 7 __libc_start_main+139 [0x4003ce5b] ================================================================ I have a working version of the patch, but it needs a bit of cleanup and testing before it becomes release-ready. Looking forward for the comments/feedback on this approach. -- Bharata B Rao, IBM Linux Technology Center, IBM Software Lab, Bangalore, India. Ph: 91-80-5044962(5262355 X-3962), Mail: bh...@in.... |