(57)【要約】【課題】ＯＳの挙動もログに取ることができ、ユーザ空間でのメモリ破壊が原因の不具合も検出可能な情報処理装置を提供することを目的とする。【解決手段】開示の情報処理装置の一形態は、ユーザ空間上に存在する複数のプロセス間でカーネル空間を介したプロセス間通信を行い、該プロセス間通信のログを記録する情報処理装置であって、前記プロセス間通信に関し、前記カーネル空間内におけるログを記録するログ記録手段を有することを特徴とする。【選択図】図５
2011034552.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ空間上に存在する複数のプロセス間でカーネル空間を介したプロセス間通信を行い、該プロセス間通信のログを記録する情報処理装置であって、
前記プロセス間通信に関し、前記カーネル空間内におけるログを記録するログ記録手段を有することを特徴とする情報処理装置。
【請求項２】
前記ログ記録手段は、クライアントプログラム動作確認のためのログを取得するための第１の種類のログポイントと、サーバプログラム動作確認のためのログを取得するための第２の種類のログポイントと、カーネル動作確認のためのログを取得するための第３の種類のログポイントとを有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ログ記録手段は、送信側プロセスが送信するパケットを送信側ｓｏｃｋｅｔバッファに書き込む箇所、該パケットを受信側ｓｏｃｋｅｔバッファに接続する箇所、受信側プロセスが呼び出す所定の関数によるメッセージパケット到着の待ち合わせが解除される箇所、該受信側プロセスが該パケットのヘッダ部を読み出す箇所、及び該受信側プロセスがパケットのメッセージ部分を読み出す箇所のうち何れか一以上におけるログを記録することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記送信側ｓｏｃｋｅｔは、前記プロセス間通信専用であって、前記送信側プロセスが送信するパケットに対し、該プロセス間通信に関するパケットであることを示す識別情報を付し、
前記ログ記録手段は、前記識別情報の付された前記パケットに関するログを記録することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
ユーザ空間上に存在する複数のプロセス間でカーネル空間を介したプロセス間通信を行い、該プロセス間通信のログを記録する情報処理装置における情報処理方法であって、
ログ記録手段が、前記プロセス間通信に関し、前記カーネル空間内におけるログを記録するステップを有することを特徴とする情報処理方法。
【請求項６】
前記ログ記録手段は、クライアントプログラム動作確認のためのログを取得するための第１の種類のログポイントと、サーバプログラム動作確認のためのログを取得するための第２の種類のログポイントと、カーネル動作確認のためのログを取得するための第３の種類のログポイントとを有することを特徴とする請求項５に記載の情報処理方法。
【請求項７】
前記ログ記録手段は、送信側プロセスが送信するパケットを送信側ｓｏｃｋｅｔバッファに書き込む箇所、該パケットを受信側ｓｏｃｋｅｔバッファに接続する箇所、受信側プロセスが呼び出す所定の関数によるメッセージパケット到着の待ち合わせが解除される箇所、該受信側プロセスが該パケットのヘッダ部を読み出す箇所、及び該受信側プロセスがパケットのメッセージ部分を読み出す箇所のうち何れか一以上におけるログを記録することを特徴とする請求項６に記載の情報処理方法。
【請求項８】
前記送信側ｓｏｃｋｅｔは、前記プロセス間通信専用であって、前記送信側プロセスが送信するパケットに対し、該プロセス間通信に関するパケットであることを示す識別情報を付し、
前記ログ記録手段は、前記識別情報の付された前記パケットに関するログを記録することを特徴とする請求項７に記載の情報処理方法。
【請求項９】
コンピュータに、請求項５乃至８の何れか一に記載の情報処理方法を実行させるための情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロセス間通信のログを取得・記録する技術に関する。
【背景技術】
【０００２】
１つの情報処理装置は、単一のプログラム集合で作られるのではなく、複数のモジュール(プロセスと呼ばれる)に分割され、それらが協調動作する。この時、これらのプロセスは協調動作のために、互いに通信を行なう。これをＩＰＣ（Inter Process Communication）と呼ぶが、そのＩＰＣの実装の一種としてｓｏｃｋｅｔが挙げられる。
【０００３】
図１では、このｓｏｃｋｅｔを利用したＩＰＣの仕組みを示す。すなわち、クライアントプロセスがサーバプロセスに向かってメッセージを送信する場合、まずメッセージパケットをクライアントが準備する。このパケットは、例として図２のような内容を持っている。送信データの前にヘッダが付き、その中にＩＰＣで呼び出すサーバのＡＰＩ（Application Program Interface） ＩＤ番号、パケットの全体サイズ、メッセージを送信した元のプロセス番号などが入っている。
【０００４】
図１に戻り、このパケットはクライアントから直接サーバに送りつけられるのではなく、まずＯＳ(Operating System, kernel)のｓｏｃｋｅｔと呼ばれる場所に届けられる。ここでｋｅｒｎｅｌはパケットをｍｂｕｆという構造で包む。次に、このｍｂｕｆを送信先のｓｏｃｋｅｔの持っている受信バッファに繋げる。受信バッファには到着していて、まだ引き取られていないｍｂｕｆが複数個繋がっている。
【０００５】
サーバプロセスは送信先ｓｏｃｋｅｔにｓｅｌｅｃｔ（）という関数を呼び出すことでメッセージパケットの到着を待ち合わせている。送信先ｓｏｃｋｅｔの受信バッファにｍｂｕｆが到着すると、このｓｅｌｅｃｔ（）待ち合わせが解除され、サーバプロセスが再び動きだす。サーバプロセスはｓｅｌｅｃｔ（）の結果からｓｏｃｋｅｔにパケットが到着していることを知り、まずパケットのヘッダ部分を読み出す。このヘッダの中に入っているメッセージの全体サイズ情報を頼りに残りの送信データをｓｏｃｋｅｔから読み出す。サーバプロセスはヘッダのＡＰＩ ＩＤを元にサーバ内部のＡＰＩを割り出し、当該ＡＰＩに対して送信データを送りつける。
【０００６】
このようなｓｏｃｋｅｔ経由のＩＰＣ通信をデバッグする際、従来技術ではユーザ空間上に用意した共有メモリにユーザ空間で動作するプロセス(おそらくはＩＰＣ通信ライブラリ)がログを書き出すことによって行なっていた（図３、特許文献１−３等）。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、このような方式では、ユーザ空間内で起きた現象のデバッグを行なうことができるが、ＯＳ内部(ｋｅｒｎｅｌと呼ばれる)で起きた不具合は観測することができないという問題点があった。また、ユーザ空間でのメモリ破壊が起きることがあり、その結果ユーザ空間からＯＳに渡されたパケットが破壊されることもあり、このような不具合をユーザ空間でのログからだけでは解析が困難であるという問題点もあった。
【０００８】
そこで、本発明では、上記問題点に鑑み、ＯＳの挙動もログに取ることができ、ユーザ空間でのメモリ破壊が原因の不具合も検出可能な情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
開示の情報処理装置の一形態は、ユーザ空間上に存在する複数のプロセス間でカーネル空間を介したプロセス間通信を行い、該プロセス間通信のログを記録する情報処理装置であって、前記プロセス間通信に関し、前記カーネル空間内におけるログを記録するログ記録手段を有することを特徴とする。
【発明の効果】
【００１０】
開示の情報処理装置は、ＯＳの挙動もログに取ることができ、ユーザ空間でのメモリ破壊が原因の不具合も検出することができる。
【図面の簡単な説明】
【００１１】
【図１】ｓｏｃｋｅｔを利用したＩＰＣの仕組みを示す図である。
【図２】ＩＰＣパケットの一例を示す図である。
【図３】従来技術を説明する図である。
【図４】本実施の形態に係る情報処理装置のソフトウェア階層を示す図である。
【図５】本実施の形態に係る情報処理装置の動作（その１）を説明する図である。
【図６】一般的なｓｏｃｋｅｔの動作を説明する図である。
【図７】本実施の形態に係る情報処理装置の動作（その２）を説明する図である。
【図８】本実施の形態に係る情報処理装置の動作（その３）を説明する図である。
【図９】本実施の形態に係る情報処理装置の動作（その４）を説明する図である。
【発明を実施するための形態】
【００１２】
図面を参照しながら、本発明を実施するための最良の形態について説明する。
【００１３】
図４は本実施の形態に係る情報処理装置１００のソフトウェア階層を示す図である。
【００１４】
図４において、情報処理装置１００は、クライアントプロセス１５０とサーバプロセス１６０とカーネル１７０とを備えている。クライアントプロセス１５０とサーバプロセス１６０とカーネル１７０は、それぞれの領域内でメモリ破壊が起きても他に波及しない。例えば、サーバプロセス１６０内でメモリ破壊が起きても、クライアントプロセス１５０やカーネル１７０にメモリ破壊は波及しない。
【００１５】
クライアントプロセス１５０とサーバプロセス１６０には、ＩＰＣに関する処理を行うプログラムの集合体であるＩＰＣライブラリが設けられている。クライアントプロセス１５０、サーバプロセス１６０は、ＩＰＣライブラリの機能によりカーネル１７０に対してＲｅａｄ、Ｗｒｉｔｅのシステムコールを行う。
【００１６】
カーネル１７０には、ｓｏｃｋｅｔ１１０、１２０が設けられ、それぞれの内部に設けられた受信バッファに対してメッセージのパケットを送信する。
１．第１の実施例：ＯＳ（ｋｅｒｎｅｌ）内でのｓｏｃｋｅｔログ取得
従来技術の問題を解決するために、ＯＳ内部のカーネル空間１４０でログを取得する。ＩＰＣの実装方式は様々存在するが、ここではＢＳＤ（Berkeley Software Distribution） ｓｏｃｋｅｔを使った場合の例について述べる。図５に示すように、カーネル空間１４０でのログは、ログポイントＣ、ログポイントＳ、ログポイントＫの３種類の箇所で取得する。それぞれのログポイントは次のように異なる目的を持っている。
【００１７】
ログポイントＣ
クライアントプログラム動作確認のためのログを取得するためのポイントである。このログにより、クライアントプログラムが確かにメッセージを送信したことを確認することができる。また、メッセージの内容が意図したものかどうかログから確認することができる。
【００１８】
ログポイントＳ
サーバプログラム動作確認のためのログを取得するためのポイントである。サーバプログラムが確かにメッセージを受信したことを確認することができる。また、メッセージの内容が意図したものかどうかログから確認することができる。
【００１９】
ログポイントＫ
ｋｅｒｎｅｌ動作確認のためのログを取得するためのポイントである。ｋｅｒｎｅｌが確かにメッセージを配信したことを確認することができる。メッセージ配信によってサーバプログラムをスケジューリング対象にしたことを確認することができる。経験上、このスケジューリング対象にする処理に問題が起きるケースが多数あるため、有効である。
【００２０】
以下、図５の個々のログポイントについて付記する。
【００２１】
（１）クライアントプロセス１５０からＯＳ内部のクライアント側のｓｏｃｋｅｔ１１０へのパケット送信箇所
ユーザ空間１３０からカーネル空間１４０へのパケット送信の入口でログを取得し、記録する。ここで、パケットのヘッダのサイズ情報とパケット全体サイズとが等しくない場合にはユーザ空間１３０でメモリ破壊が起きている可能性がある。
【００２２】
（２）ｓｏｃｋｅｔ(クライアントプロセス１５０側)１１０からｓｏｃｋｅｔ(サーバプロセス１６０側)１２０のバッファへパケットを接続する箇所
ｓｏｃｋｅｔは、ＩＰＣ用のパケットだけを扱う訳ではないので、サーバプロセス１６０側のｓｏｃｋｅｔ１２０へ届けたかどうか検証することができる。
【００２３】
（３）サーバプロセス１６０がｓｏｃｋｅｔバッファへのパケット到着によって、待ち合わせを解除する箇所
サーバプロセス１６０はｓｅｌｅｃｔ（）システムコールでＩＰＣパケットの到着を待ち合わせているが、このｓｅｌｅｃｔ（）がスレッドライブラリとの相性などの問題で不具合がよく見つかることがあった。バッファへのパケット接続によってｓｅｌｅｃｔ（）が解除されたのか否かについて、ログを取ることでそのような不具合の解析を行なうことができる。
【００２４】
（４）サーバプロセス１６０がｓｏｃｋｅｔ１２０からパケットのヘッダ部を読み出す箇所
サーバプロセス１６０のＩＰＣライブラリは最初にヘッダ部を読み出し、残りのパケットサイズを知る。
【００２５】
（５）サーバプロセス１６０がｓｏｃｋｅｔ１２０からパケットの残りを読み出す箇所
サーバプロセス１６０が残りのパケットを読み出す。ここまで来て本当にパケットがクライアントプロセス１５０からサーバプロセス１６０まで送信されたことになる。何らかの原因で読み出すサイズと到着していたパケット残りサイズとが異なっていた場合、ｒｅａｄ（）がエラー終了する。この場合メモリ破壊の疑いがあることになる。
【００２６】
このようなログポイントをＯＳ内部に設けることで、カーネル空間１４０のパケット配送状況のデバッグが可能に、またユーザ空間１３０からカーネル空間１４０に渡ってきたパケットが正常なフォーマットになっているか否かについてチェック（上記（１）などで）をすることができる。
【００２７】
２．第２の実施例：ＩＰＣパケットのみをログ取得対象とする
第１の実施例ではｓｏｃｋｅｔ経由のパケット配信コードにログポイントを仕掛けることで、パケットの配信状況をログに取ることができた。しかし、図６で示すように、ｓｏｃｋｅｔを通るパケットはＩＰＣ用のパケットには限られない。
【００２８】
ｓｏｃｋｅｔは、ネットワークを汎用的に扱うための仕組みで、ＩＰＣはそれを利用する通信方式の一つなのである。当然別のｓｏｃｋｅｔがプロトコルを扱う際には、パケットにＩＰＣ形式のヘッダが付いていることは期待できない。
【００２９】
そこで、図７で示すように、クライアントプロセス１５０は、サーバプロセス１６０とＩＰＣ ｓｏｃｋｅｔを接続した後に、ｓｏｃｋｅｔ１１０にＩＰＣマークを付ける。クライアントプロセス１５０は、ＩＰＣマークを付記後、当該ｓｏｃｋｅｔ１１０に対してパケットのｗｒｉｔｅ（）を行なう。すると、カーネル空間１４０のｓｏｃｋｅｔ管理コードは、ＩＰＣマークの付記されたｓｏｃｋｅｔ１１０で受信したパケットをｍｂｕｆ構造で包む際に、ログマークを付記する。このような処理をすることで、ＩＰＣに関連するパケットのｍｂｕｆにはログマークが必ず付記されることとなる。
【００３０】
上記は、ＩＰＣのｍｂｕｆにログマークを付ける方式だが、別の手段も考えられる。図８で示すように、ＩＰＣはサーバプロセス１６０がＩＰＣポートを開く際、ｓｏｃｋｅｔファイルをシステム（カーネル空間上）のファイルシステムに生成する。そのｓｏｃｋｅｔファイルの生成場所を「／ｓｏｃｋｅｔ」など所定のディレクトリに生成するようＩＰＣライブラリで規約を作れば、ＯＳは、「／ｓｏｃｋｅｔ」に生成されたｓｏｃｋｅｔファイルに対してクライアントプロセス１５０がｓｏｃｋｅｔ１１０を開こうとした際、その当該ｓｏｃｋｅｔ１１０にＩＰＣマークを付ける。後はＩＰＣマークが付いたｓｏｃｋｅｔ１１０を通るｍｂｕｆにログマークを付けるのは、図７で示した例と同様である。
【００３１】
上記例のような方式で、ｍｂｕｆにはログマークが付記される。図９で示すように、第１の実施例のようなカーネル空間１４０のログポイントでは、このログマークの付いたｍｂｕｆのみをログ取得対象とする。このようなログ取得・記録形式を採用することで、汎用的なｓｏｃｋｅｔシステムを通るパケットの中からＩＰＣに関連するパケットのみをログ取得対象とすることができる。
【００３２】
（総括）
上記のように、開示の情報処理装置の一形態は、ＯＳの挙動もログに取ることができ、ＯＳに渡って来た際のパケットを解析できるので、ユーザ空間でのメモリ破壊が原因の不具合も検出することができる。
また、開示の情報処理装置の一形態は、ＩＰＣ用に確保されたｓｏｃｋｅｔをＯＳが認識できるので、ログ記録対象パケットをＯＳが判断することができる。
また、開示の情報処理装置の一形態は、ＯＳのネットワーク配信システムがＩＰＣパケットとそれ以外のパケットを識別できるので、ＩＰＣ用のパケットだけに注目してログ記録をＯＳが行なうことができる。
また、開示の情報処理装置の一形態は、ＯＳのネットワーク配信システムがＩＰＣパケットとそれ以外のパケットを識別できるので、ＩＰＣ用のパケットだけに注目してログ記録をＯＳが行なうことができる。また、ＩＰＣと全く無関係の箇所にパケットが配信されてしまうような不具合があったとしても、ログ記録ポイントを適切に設定することで追跡することができる。
また、開示の情報処理装置の一形態は、ＯＳ内部でログ記録をしているので、ＯＳに確かにパケットが届いたことを検出できる。ＯＳに届いた際のパケット内容を検査してエラー検出することができる。
また、開示の情報処理装置の一形態は、ＯＳ内部でログ記録をしているので、ＯＳ内部のネットワーク配信システムの不具合をログから解析することができる。
また、開示の情報処理装置の一形態は、ＯＳ内部でログ記録をしているので、ＯＳ内部のネットワーク配信システムの不具合をログから解析することができる。ｓｅｌｅｃｔ（）が外れた原因がパケットの到着であったのか否かについて検証することができる。
また、開示の情報処理装置の一形態は、ｒｅａｄ（）システムコールがＯＳに届いたかどうかログに記録できるので、ｓｅｌｅｃｔ（）が解除された後、正常にサーバのＩＰＣスレッドが動作再開していることを検証することができる。
また、開示の情報処理装置の一形態は、ｒｅａｄ（）システムコールがＩＰＣのパケットと同一のサイズを読み出そうとしているのかＯＳ側でチェックでき、パケットのヘッダ内情報とパケット全体サイズが等しいかチェックできるので、ＯＳ内部もしくはＩＰＣ送信元ユーザプログラムによるメモリ破壊を検出することができる。
【００３３】
以上、本発明の実施の形態について詳述したが、本発明は係る特定の実施の形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲において、種々の変形・変更が可能である。
【符号の説明】
【００３４】
１００      情報処理装置
１１０      ｓｏｃｋｅｔ
１２０      ｓｏｃｋｅｔ
１３０      ユーザ空間
１４０      カーネル空間
１５０      クライアントプロセス
１６０      サーバプロセス
１７０      カーネル
【先行技術文献】
【特許文献】
【００３５】
【特許文献１】特開２００１−３１８８１０号公報
【特許文献２】特開２００３−１５０３５７号公報
【特許文献３】特開平５−６１７３２号公報
【図１】
2011034552.tif 000003
【図２】
2011034552.tif 000004
【図３】
2011034552.tif 000005
【図４】
2011034552.tif 000006
【図５】
2011034552.tif 000007
【図６】
2011034552.tif 000008
【図７】
2011034552.tif 000009
【図８】
2011034552.tif 000010
【図９】
2011034552.tif 000011