pstack to find line number of crash - Unix

This is a discussion on pstack to find line number of crash - Unix ; Hi there, Below is the pstack of the core file: ffffffff7752910c __1cOCTelnetSessionIReadLine6Mpci_i_ (16f968568, 16f9683b0, 200, 1, 33110c, ffffffff7785a078) + 1a4 ffffffff77528e84 __1cOCTelnetSessionHConnect6Mpwi_b_ (16f968568, 124242f50, 1090, 0, 20, 14e5b0590) + 34c ffffffff77524a98 __1cSCJoinEngineSessionHConnect6Mi_b_ (280, 1e, 13107d1d0, 13107f9a8, ffffffff77526450, ffffffff7785a078) + 12c ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: pstack to find line number of crash

  1. pstack to find line number of crash

    Hi there,

    Below is the pstack of the core file:
    ffffffff7752910c __1cOCTelnetSessionIReadLine6Mpci_i_ (16f968568,
    16f9683b0, 200, 1, 33110c, ffffffff7785a078) + 1a4
    ffffffff77528e84 __1cOCTelnetSessionHConnect6Mpwi_b_ (16f968568,
    124242f50, 1090, 0, 20, 14e5b0590) + 34c
    ffffffff77524a98 __1cSCJoinEngineSessionHConnect6Mi_b_ (280, 1e,
    13107d1d0, 13107f9a8, ffffffff77526450, ffffffff7785a078) + 12c

    How can I find the code/line being obeyed at CTelnetSession::ReadLine
    + 1a4?

    How can I get the line number where it crashed?

    I had compiled the application using -g option on Solaris.

    I can't use dbx/gdb to debug the core file as we don't have the user
    environment at our end.
    Any help or pointers will be highly appreciated.

  2. Re: pstack to find line number of crash

    funwithdolphin writes:

    > Below is the pstack of the core file:
    > ffffffff7752910c __1cOCTelnetSessionIReadLine6Mpci_i_ (...) + 1a4
    > ffffffff77528e84 __1cOCTelnetSessionHConnect6Mpwi_b_
    > ffffffff77524a98 __1cSCJoinEngineSessionHConnect6Mi_b_

    ....
    > How can I find the code/line being obeyed at CTelnetSession::ReadLine
    > + 1a4?


    Use debugger, such as dbx or mdb.

    > How can I get the line number where it crashed?


    How is the second question different from the first?

    > I had compiled the application using -g option on Solaris.
    >
    > I can't use dbx/gdb to debug the core file as we don't have the user
    > environment at our end.


    You can ask the end-user to obtain the stack trace for you:

    dbx /path/to/exe /path/to/core
    (dbx) where

    Otherwise, you can still find out which line of
    'CTelnetSession::ReadLine(char*,int)' the address 0xffffffff7752910c
    corresponds to, but more info is required: you need to know where
    the shared library providing ReadLine was loaded
    ('pmap /path/to/exe /path/to/core' will answer that).

    Once you know the load address (let's call it LADDR), do this:

    gdb /path/to/shared-lib.so
    (gdb) info line __1cOCTelnetSessionIReadLine6Mpci_i_
    # should answer with 'starts at 0xNNNN, ends at 0xMMMM'
    # and the interval should "cover" (overlap) 0xffffffff7752910c-LADDR

    (gdb) info line first_line_of_ReadLine
    # should give you a range of addresses

    (gdb) info line first_line_of_ReadLine+1
    # should give you a range of addresses

    Continue until you reach a line that "covers" 0xffffffff7752910c-LADDR

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: pstack to find line number of crash

    On Dec 17, 8:31 pm, Paul Pluzhnikov wrote:
    > funwithdolphin writes:
    > > Below is the pstack of the core file:
    > > ffffffff7752910c __1cOCTelnetSessionIReadLine6Mpci_i_ (...) + 1a4
    > > ffffffff77528e84 __1cOCTelnetSessionHConnect6Mpwi_b_
    > > ffffffff77524a98 __1cSCJoinEngineSessionHConnect6Mi_b_

    > ...
    > > How can I find the code/line being obeyed at CTelnetSession::ReadLine
    > > + 1a4?

    >
    > Use debugger, such as dbx or mdb.
    >
    > > How can I get the line number where it crashed?

    >
    > How is the second question different from the first?
    >
    > > I had compiled the application using -g option on Solaris.

    >
    > > I can't use dbx/gdb to debug the core file as we don't have the user
    > > environment at our end.

    >
    > You can ask the end-user to obtain the stack trace for you:
    >
    > dbx /path/to/exe /path/to/core
    > (dbx) where
    >
    > Otherwise, you can still find out which line of
    > 'CTelnetSession::ReadLine(char*,int)' the address 0xffffffff7752910c
    > corresponds to, but more info is required: you need to know where
    > the shared library providing ReadLine was loaded
    > ('pmap /path/to/exe /path/to/core' will answer that).
    >
    > Once you know the load address (let's call it LADDR), do this:
    >
    > gdb /path/to/shared-lib.so
    > (gdb) info line __1cOCTelnetSessionIReadLine6Mpci_i_
    > # should answer with 'starts at 0xNNNN, ends at 0xMMMM'
    > # and the interval should "cover" (overlap) 0xffffffff7752910c-LADDR
    >
    > (gdb) info line first_line_of_ReadLine
    > # should give you a range of addresses
    >
    > (gdb) info line first_line_of_ReadLine+1
    > # should give you a range of addresses
    >
    > Continue until you reach a line that "covers" 0xffffffff7752910c-LADDR
    >
    > Cheers,
    > --
    > In order to understand recursion you must first understand recursion.
    > Remove /-nsp/ for email.


    Thanks a lot for the help. I have understood this now.

  4. Re: pstack to find line number of crash

    On Dec 19 2007, 7:19*pm, funwithdolphin
    wrote:
    > On Dec 17, 8:31 pm, Paul Pluzhnikov wrote:
    >
    >
    >
    >
    >
    > > funwithdolphin writes:
    > > > Below is the pstack of the core file:
    > > > ffffffff7752910c __1cOCTelnetSessionIReadLine6Mpci_i_ (...) + 1a4
    > > > ffffffff77528e84 __1cOCTelnetSessionHConnect6Mpwi_b_
    > > > ffffffff77524a98 __1cSCJoinEngineSessionHConnect6Mi_b_

    > > ...
    > > > How can I find the code/line being obeyed at CTelnetSession::ReadLine
    > > > + 1a4?

    >
    > > Use debugger, such as dbx or mdb.

    >
    > > > How can I get the line number where it crashed?

    >
    > > How is the second question different from the first?

    >
    > > > I had compiled the application using -g option on Solaris.

    >
    > > > I can't use dbx/gdb to debug the core file as we don't have the user
    > > > environment at our end.

    >
    > > You can ask the end-user to obtain the stack trace for you:

    >
    > > * dbx /path/to/exe /path/to/core
    > > * (dbx) where

    >
    > > Otherwise, you can still find out which line of
    > > 'CTelnetSession::ReadLine(char*,int)' the address 0xffffffff7752910c
    > > corresponds to, but more info is required: you need to know where
    > > the shared library providing ReadLine was loaded
    > > ('pmap /path/to/exe /path/to/core' will answer that).

    >
    > > Once you know the load address (let's call it LADDR), do this:

    >
    > > gdb /path/to/shared-lib.so
    > > (gdb) info line __1cOCTelnetSessionIReadLine6Mpci_i_
    > > # should answer with 'starts at 0xNNNN, ends at 0xMMMM'
    > > # and the interval should "cover" (overlap) 0xffffffff7752910c-LADDR

    >
    > > (gdb) info line first_line_of_ReadLine
    > > # should give you a range of addresses

    >
    > > (gdb) info line first_line_of_ReadLine+1
    > > # should give you a range of addresses

    >
    > > Continue until you reach a line that "covers" 0xffffffff7752910c-LADDR

    >
    > > Cheers,
    > > --
    > > In order to understand recursion you must first understand recursion.
    > > Remove /-nsp/ for email.

    >
    > Thanks a lot for the help. I have understood this now.- Hide quoted text -
    >
    > - Show quoted text -


    any idea how to check in case of multi thread enabled exes

  5. Re: pstack to find line number of crash

    sr_nandan1@hotmail.com writes:

    > any idea how to check in case of multi thread enabled exes


    In exactly the same way.

    You may also wish to read this:
    http://catb.org/esr/faqs/smart-questions.html

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

+ Reply to Thread