シグナルの送信元について

[A_Ma]

当方で作成したアプリケーションをHP-UX上で動作させていたところ、突然SIGABORTを受信する現象が時々発生しています。その他のアプリケーションでSIGABORTを送信するものは心当たりありません。

HP-UXで、シグナル送信元（pidなど）を探り当てる方法は無いものでしょうか？

どなたかご存知の方、ご教示下さい。

[S.Takeda]

アプリケーション自身のプロセスの中で、abort関数がコールされている可能性はないでしょうか？　例えば、アプリケーションがコールしているライブラリの関数の中でabort関数はコールされる場合。

この様な場合、coreが出力されているのであれば、デバッガ（gdb)等でスタックを確認することにより原因を絞ることが出来ると考えます。

[oops]

SIGABRT なら core ができているはずです。S.Takeda さんも書かれていますが、core を gdb 等で解析されてはどうでしょうか？

SIGABRT を受信する理由としては、

- 自身で abort()、raise()、kill() を呼ぶ

core からスタックトレースをとればすぐにわかります。

- 同期的に受信する。

SIGABRT と SIGIOT は同じ signal 番号で、bsh や posix 系では SIGABRT、csh なら SIGIOT と表示されます。例えば、libdl(d)を使用している状況で稼動中に dld が unsatisfied symbol を検出したりすると、SIGABRT を送信します。これもコアを見ることで予測はできますが、共有ライブラリが絡むので、見方は難しいです。

- 他のプロセスが sigsend() や kill() で SIGABRT を送信する。

これを捕まえるためには、SA_SIGINFO をたてた sigaction() で SIGABRT をハンドルするようにプログラムを変更するか、高信頼性システムにｓて該当システムコールの audit をとるくらいしか浮かびません。どっちにしても大変だと思います。

[A_Ma]

S.Takeda様、oops様、回答ありがとうございました。coreを解析したところ、当該アプリが使用している汎用ミドルのライブラリ(Visibroker)の中で発生していることがわかりました。ただ、ミドル内部であることから、ソースコードが見られず、このライブラリがabort()などをコールしているのか、あるいは本当に他プロセスからSIGABORTが送られているのかについては不明で、この切り分けについてはoops様のおっしゃる「SA_SIGINFOをたてたsigaction()でSIGABRT をハンドルするようにプログラムを変更する」の方法で行うように検討してみます。ありがとうございました。

[oops]

スタックトレースに abort() とかは表示されなかったのでしょうか？

ミドルウェアの方が strip されていたとしても、abort() は libc 内のシステムコールなので、表示されてもいいはずですが...

スタック上にないのであれば、他から送信された可能性が高くなりますね。