vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| I understand that we can analyze core file of processes that died, but what about processes that hangs forever, consuming CPU? Is there any particular approach we can take to analyze the hanging process? We don't own source code of this process executable, so we cannot try generating trace file. Thank you in advance. |
| |||
| On Thu, 31 Aug 2006 23:47:16 -0400 Forte Agent <robertch@newscat.com> wrote: > I understand that we can analyze core file of processes that died, but > what about processes that hangs forever, consuming CPU? Is there any > particular approach we can take to analyze the hanging process? We > don't own source code of this process executable, so we cannot try > generating trace file. You can use tusc to trace the process while it runs. You can download the tusc shar file from: <http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,2894,00.html> I doubt your program has been compiled with symbols, but the WDB debugger (a HP supported version of the GNU debugger GDB) can be attached to a running program. Check HP's WDB page at <http://www.hp.com/go/wdb/>. Take care, -- Stefaan A Eeckels -- "What is stated clearly conceives easily." -- Inspired sales droid |
| |||
| Forte Agent wrote: > I understand that we can analyze core file of processes that died, but > what about processes that hangs forever, consuming CPU? Is there any > particular approach we can take to analyze the hanging process? We > don't own source code of this process executable, so we cannot try > generating trace file. Thank you in advance. Here are a few approaches you may want to try: - Attach to the process with gdb (http://www.hp.com/go/wdb), % gdb <executable> <pid> capture backtraces for each thread (gdb) thread apply all bt detach (gdb) detach - Attach to the process with gdb, generate a core file for further studies (gdb) dumpcore detach - On Integrity systems (aka systems based on Itanium processors), use Caliper (http://www.hp.com/go/caliper) to capture profiles of the code executing % caliper scgprof -o scgprof.txt --duration 60 <pid> - On PA-RISC system, you may want to use Prospect (http://www.hp.com/go/prospect) in a similar way (sorry, I don't know the exact invocation) - On up-to-date Integrity systems, you should have a tool called pstack that can capture the current callstack of all threads in the given process (similar to "thread apply all bt" in gdb) - Other interesting tools: - glance (syscall profile, etc.) - tusc (syscall trace) Eric |
| |||
| Thank you Eric and Stefaan. I'll try the tips you suggested. On Fri, 1 Sep 2006 09:21:54 +0200, Stefaan A Eeckels <hoendech@ecc.lu> wrote: >On Thu, 31 Aug 2006 23:47:16 -0400 >Forte Agent <robertch@newscat.com> wrote: > >> I understand that we can analyze core file of processes that died, but >> what about processes that hangs forever, consuming CPU? Is there any >> particular approach we can take to analyze the hanging process? We >> don't own source code of this process executable, so we cannot try >> generating trace file. > >You can use tusc to trace the process while it runs. You can download >the tusc shar file from: > ><http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,2894,00.html> > >I doubt your program has been compiled with symbols, but the WDB >debugger (a HP supported version of the GNU debugger GDB) can be >attached to a running program. Check HP's WDB page at ><http://www.hp.com/go/wdb/>. > >Take care, > >-- >Stefaan A Eeckels |
| ||||
| in addition to what eric suggested, you could try invoking the program from within gdb itself (if attaching does not work as in some rare cases). this may not be straightforward if your application is usually started up by something like another program, a wrapper script etc. so you can keep this approach for last. -- please dont reply by email |