When process hangs forever - HP UX

This is a discussion on When process hangs forever - HP UX ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: When process hangs forever

  1. When process hangs forever




    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.






  2. Re: When process hangs forever

    On Thu, 31 Aug 2006 23:47:16 -0400
    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.


    You can use tusc to trace the process while it runs. You can download
    the tusc shar file from:



    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
    .

    Take care,

    --
    Stefaan A Eeckels
    --
    "What is stated clearly conceives easily." -- Inspired sales droid

  3. Re: When process hangs forever

    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
    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

    - 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

  4. Re: When process hangs forever



    Thank you Eric and Stefaan. I'll try the tips you suggested.





    On Fri, 1 Sep 2006 09:21:54 +0200, Stefaan A Eeckels
    wrote:

    >On Thu, 31 Aug 2006 23:47:16 -0400
    >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.

    >
    >You can use tusc to trace the process while it runs. You can download
    >the tusc shar file from:
    >
    >
    >
    >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
    >.
    >
    >Take care,
    >
    >--
    >Stefaan A Eeckels



  5. Re: When process hangs forever


    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

+ Reply to Thread