HP-UX11i，ストールしているプロセスをデバッグする

はじめに≫
　HP-UX11iにて
　C/C++ 言語のプログラムをデバッグする方法だが。

　知ってる人は良く知ってるが、
　知らない（デバッガ使ったことがない）人は、
　デバッガを使う事さえも見当つかないようだ。

　そんな初心者のために、
　‘凡庸’から
　愛情を込めて♪
　デバッガの使い方を伝授。

準備≫
　ストールしているプロセスを確認する。
    % ps -ef | grep simpserv
        hoge  6774  6759  0 17:38:02 ?         0:00 simpserv 41 7 -r -e stderr.out
    %

　プロセスＩＤ（ｐｉｄ）は　６７７４　だ。

  “simpserv”は、
純正“HP ANSI C / HP-UX”コンパイラで、“－ｇ”オプション付きでコンパイルしている。

　ちなみに、ＯＳは
    % uname -srm
    HP-UX B.11.23 ia64
    %

手順≫
１）デバッガを起動。
    % gdb
    HP gdb 5.2 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
    Copyright 1986 - 2001 Free Software Foundation, Inc.
    Hewlett-Packard Wildebeest 5.2 (based on GDB) is covered by the
    GNU General Public License. Type "show copying" to see the conditions to
    change it and/or distribute copies. Type "show warranty" for warranty/support.

    (gdb)

　GNU gdb を移植してはるようだ、ＨＰさんは。
　ということは、
　“HP ANSI C/HP-UX” とgcc はオブジェクト・レベルで互換性があるのか？！
　後日試してみよう。

２）ｐｉｄを指定して対象プロセスにアタッチする。
    (gdb) attach 6774
    Attaching to program: /homea/nzpf/service_parts/simpserv, process 6774
    warning: The shared libraries were not privately mapped; setting a
    breakpoint in a shared library will not work until you rerun the program.
    Use the following command to enable debugging of shared libraries.
    chatr +dbg enable a.out
    0xc000000000317bb0:0 in _select_sys+0x30 () from /usr/lib/hpux64/libc.so.1
    (gdb)

３）スレッドを確認。
    (gdb) info threads
        4 system thread 43575  Priority:168  0xc00000000031cc10:0 in __sigtimedwait_sys+0x30 () from /usr/lib/hpux64/libc.so.1
        3 system thread 42490  Priority:137  0xc0000000001137b0:0 in ___lwp_wait_sys+0x30 () from /usr/lib/hpux64/libpthread.so.1
        2 system thread 42489  Priority:168  0xc00000000031cc90:0 in __sigwait_sys+0x30 () from /usr/lib/hpux64/libc.so.1
    *   1 system thread 42488  Priority:154  0xc000000000317bb0:0 in _select_sys+0x30 () from /usr/lib/hpux64/libc.so.1
    (gdb)

　４番スレッドがアプリを実行しているスレッドと思われるので、
　そちらにアタッチ

    (gdb) thread 4
    [Switching to thread 4 (system thread 43575)]
    #0  0xc00000000031cc10:0 in __sigtimedwait_sys+0x30 () from /usr/lib/hpux64/libc.so.1
    (gdb)

４）スタックトレースを確認。
    (gdb) where
    #0  0xc00000000031cc10:0 in __sigtimedwait_sys+0x30 () from /usr/lib/hpux64/libc.so.1
    #1  0xc00000000032b4d0:0 in sigtimedwait+0xb0 () from /usr/lib/hpux64/libc.so.1
    #2  0xc000000000243bc0:0 in sleep+0x120 () from /usr/lib/hpux64/libc.so.1
    #3  0x40000000000013a0:0 in TOUPPER () at simpserv.c:183
    #4  0xc0000000000b1c00:0 in __pthread_bound_body+0x190 () from /usr/lib/hpux64/libpthread.so.1
    (gdb)

５）アプリケーションのどこでストールしているのか
　　ソースを確認。
    (gdb) up 3
    #3  0x40000000000013a0:0 in TOUPPER () at simpserv.c:183
    183             sleep(30);
    (gdb) list
    178
    179
    180
    181         for(i = 0; i < rqst->len; i++) {
    182             rqst->data[i] = (char)toupper((int)rqst->data[i]);
    183             sleep(30);
    184         }
    185
    186
    187

　sleep させてやした。　　　(*^_^*)
　わざとやで～。

６）終わる。
    (gdb) detach
    Detaching from program: /home/hoge/simpserv, process 6774
    (gdb) quit
    %

あとがき≫
　Solaris ぢゃ
　gcore コマンドでコア・ダンプ吐かせて、
　それをデバッガ（Ｓｕｎ純正だと dbxコマンド）に食べさせてたが、
　これだと、
　稼動中のプロセスもデバッグできちゃうのね。

　知らんかった。

　ＳＥ稼業２０年だけど、知らないことばっかり。　(-_-;)
　安穏とできるのはいつのことやら。

以上だし