tusc output - confused - HP UX

This is a discussion on tusc output - confused - HP UX ; this is tusc output:- [23337] write(1, "1b[ 4 7 ; 1 H 1b[ M \n\n\nP r e ".., 40) ....... = 40 [23337] sigaction(SIGTSTP, 0x4000b07c, NULL) ..................... = 0 [23337] read(0, "\r", 255) ....................................... = 1 [23337] lseek64(8, 0, SEEK_CUR) ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: tusc output - confused

  1. tusc output - confused


    this is tusc output:-

    [23337] write(1, "1b[ 4 7 ; 1 H 1b[ M \n\n\nP r e ".., 40) ....... = 40
    [23337] sigaction(SIGTSTP, 0x4000b07c, NULL) ..................... = 0
    [23337] read(0, "\r", 255) ....................................... = 1
    [23337] lseek64(8, 0, SEEK_CUR) .................................. = 24
    [23337] lseek64(8, 6144, SEEK_SET) ............................... =
    6144
    [23337] read(8, "\0\0\006\0\0\005\0\0\0\a\0\0\010".., 1024) ...... =
    1024
    [23337] lseek64(8, 24, SEEK_SET) ................................. = 24
    [23337] lseek64(8, 0, SEEK_CUR) .................................. = 24
    [23337] lseek64(8, 4096, SEEK_SET) ............................... =
    4096
    [23337] read(8, "\0\0\004\0\0\003\0\0\0\n\0\0\010".., 1024) ...... =
    1024
    [23337] lseek64(8, 24, SEEK_SET) ................................. = 24
    [23337] Received signal 10, SIGBUS, in user mode, [caught], partial
    siginfo
    [23337] Siginfo: si_code: I_NONEXIST, faulting address: 0x4003f15b,
    si_errno: 0
    [23337] PC: 0xc12b7317, instruction: 0x0c601094

    Above trace doesnt show the actual culprit/victim system call.
    Im just guessing that it is while reading the file.
    What can be the cause of SIGBUS? reading corrupt file?


  2. Re: tusc output - confused

    knowledgeseeker wrote:

    > this is tusc output:-


    > [23337] write(1, "1b[ 4 7 ; 1 H 1b[ M \n\n\nP r e ".., 40) ....... = 40
    > [23337] sigaction(SIGTSTP, 0x4000b07c, NULL) ..................... = 0
    > [23337] read(0, "\r", 255) ....................................... = 1
    > [23337] lseek64(8, 0, SEEK_CUR) .................................. = 24
    > [23337] lseek64(8, 6144, SEEK_SET) ............................... =
    > 6144
    > [23337] read(8, "\0\0\006\0\0\005\0\0\0\a\0\0\010".., 1024) ...... =
    > 1024
    > [23337] lseek64(8, 24, SEEK_SET) ................................. = 24
    > [23337] lseek64(8, 0, SEEK_CUR) .................................. = 24
    > [23337] lseek64(8, 4096, SEEK_SET) ............................... =
    > 4096
    > [23337] read(8, "\0\0\004\0\0\003\0\0\0\n\0\0\010".., 1024) ...... =
    > 1024
    > [23337] lseek64(8, 24, SEEK_SET) ................................. = 24
    > [23337] Received signal 10, SIGBUS, in user mode, [caught], partial
    > siginfo
    > [23337] Siginfo: si_code: I_NONEXIST, faulting address: 0x4003f15b,
    > si_errno: 0
    > [23337] PC: 0xc12b7317, instruction: 0x0c601094


    > Above trace doesnt show the actual culprit/victim system call.
    > Im just guessing that it is while reading the file.
    > What can be the cause of SIGBUS? reading corrupt file?


    IIRC it doesn't have to have been any of those system calls - the
    SIGBUS could be for the application code chasing a bad pointer.

    You might want to look at the core file with wdb (gdb) and see what
    the stack trace tells you.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: tusc output - confused

    Rick Jones writes:

    > knowledgeseeker wrote:

    ....
    >> Above trace doesnt show the actual culprit/victim system call.


    Because system call is not a culprit, nor a victim.

    >> What can be the cause of SIGBUS? reading corrupt file?


    A bug in the program.

    > IIRC it doesn't have to have been any of those system calls


    It's even stronger than that: there are *no* system calls (other than
    "kill(getpid(), SIGBUS);" that is) which by themselves will cause
    SIGBUS to be delievered to a process.

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

  4. Re: tusc output - confused

    Eric Gouriou wrote:
    : > Received signal 10, SIGBUS, in user mode, [caught], partial siginfo
    : > Siginfo: si_code: I_NONEXIST, faulting address: 0x4003f15b,
    : > PC: 0xc12b7317, instruction: 0x0c601094

    : It is most likely due to reading multiple bytes at an incorrectly aligned
    : address, in this case 0x4003f15b.

    Exactly, the instruction is: LDWS 0(r3),r20
    So R3 is misaligned.

    : Tusc is the wrong tool for this job.
    : Eric

    It will only give you the PC, data address and the instruction.

  5. Re: tusc output - confused

    "knowledgeseeker" writes:

    > this is tusc output:-
    >

    [...]
    > [23337] lseek64(8, 24, SEEK_SET) ................................. = 24
    > [23337] Received signal 10, SIGBUS, in user mode, [caught], partial
    > siginfo
    > [23337] Siginfo: si_code: I_NONEXIST, faulting address: 0x4003f15b,
    > si_errno: 0
    > [23337] PC: 0xc12b7317, instruction: 0x0c601094
    >
    > Above trace doesnt show the actual culprit/victim system call.


    I think tusc is printing the system call after it has returned (to show you
    the result).

    > Im just guessing that it is while reading the file.
    > What can be the cause of SIGBUS? reading corrupt file?


  6. Re: tusc output - confused

    Ulrich Windl wrote:
    : > [23337] lseek64(8, 24, SEEK_SET) ................................. = 24
    : > [23337] Received signal 10, SIGBUS, in user mode, [caught], partial
    : I think tusc is printing the system call after it has returned (to show you
    : the result).

    Yes, but there could be many seconds between the lseek64 and the signal 10.

+ Reply to Thread