JP4280749B2 - ログ取得方法およびプログラム、記憶媒体 - Google Patents

Description

本発明は、複数にモジュール分けされたソフトウェアの処理ログを取得するための技術に関するものである。

従来より、再現率の低いソフトウェアの障害に対しては、ソフトウェアの処理ログを取得し、当該処理ログを解析することによって、障害の原因をつきとめ、その対策を講じてきた。

しかし、上記従来の処理ログの取得には以下のような問題点がある。
（１）ユーザの動作環境でもログを取得しつづけるためには、ソフトウェアのモジュール自体に手を加え、処理ログ取得ルーチンを追加しなければならず、処理ログ取得のための作業負荷が大きかった。
（２）処理ログ取得はモジュール毎に行うため、生成されたログはモジュール単位のものとなってしまい、ソフトウェア全体の処理を、完全に時間順のログとして取得するのが困難である。このため、全体の処理ログとしての見通しが悪く、ログを解析して障害の原因を発見するまでのプロセスに工数がかかっていた。

かかる問題を解決するための方法として、特許文献１乃至５には、それぞれ、複数にモジュール分けされたソフトウェアの処理ログを容易に取得し、ソフトウェアの障害の原因を解析するのに必要な工数を低減させるための方法が記載されている。
特願２００２−１９１１２７ 特願２００２−１９１１２８ 特願２００２−１９１１２９ 特願２００２−１９１１３０ 特願２００３−０９９４６５

しかしながら、特許文献１乃至４に記載の場合、ＥＸＥによって呼び出される全ての関数／メソッドの処理ログを取得することとしているため、取得される処理ログの数が膨大となる。特許文献５には、ＡＰＩトレーサ内において“オペレーティングシステムの範囲”ならびに“オペレーティングシステムから呼び出される例外的なモジュール”を指定することにより、ＥＸＥによって呼び出される関数／メソッドのうち、処理ログを取得する対象を、オペレーティングシステム内およびいくつかの例外的な指定モジュールに限定する旨の実施形態が示されているが、この場合も取得される処理ログの数は膨大な数となる。

本発明は、上記課題を鑑みてなされたものであり、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、パラメータを処理ログとして選択的に取得することができるログ取得方法であって、取得される処理ログの量が抑制でき、ソフトウェアの障害の原因の解析のための工数を削減することが可能なログ取得方法を提供することを目的とする。

上記の目的を達成するために本発明に係るログ取得方法は以下のような構成を備える。即ち、
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記関数を呼び出す際のパラメータが構造を指すポインタを含む場合に、当該ポインタの指す構造に含まれる更に下位レベルの構造を指す更なるポインタの探索を、現在のレベルが設定レベルに達するまで繰り返し実行し、当該設定レベルに達すると終了する工程と、
前記関数を呼び出す際のパラメータと、該パラメータが構造を指すポインタを含む場合に探索された構造のデータとを含む、前記関数を呼び出す際の情報を記録する工程と
前記実行結果を受け取った際の情報を記録する工程とを備える。

本発明によれば、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、パラメータを処理ログとして選択的に取得することができる。これにより、取得される処理ログの量が抑制でき、ソフトウェアの障害の原因の解析のための工数を削減することが可能なログ取得方法を提供することが可能となる。

なお、当該方法は、Ｊａｖａ（登録商標）アプリケーションをトレースするためだけでなく、Ｃ言語やＣ＋＋言語、パスカル等の他のプログラム言語によって作成されるアプリケーションをトレースする場合にも適用可能である。

本発明の他の特徴や効果は、下記記載ならびに添付の図面から明らかとなるであろう。

以下、必要に応じて添付図面を参照しながら本発明の各実施形態を詳細に説明する。

［第１の実施形態］
本実施形態は、あるモジュールから別のモジュール内に存在する関数の呼び出しが行われる際の仕組みである、メモリに保持されたインポート関数アドレス、または仮想関数アドレステーブル（Ｖｉｒｔｕａｌ Ａｄｄｒｅｓｓ Ｔａｂｌｅ）を利用して、モジュール間の関数呼び出しをフックしてログに記録することで、ソフトウェアのモジュール自体に手を加えることなく、ソフトウエア全体の処理を、時間順のログとして取得することを可能にするものである。以下に具体的に説明する。

＜システム構成＞
図１は、本発明の各実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。説明を簡略化するために、本実施形態では、本ソフトウェア評価システムが１台のＰＣ内部に構築されるものとするが、本発明のログ取得方法の特徴は１台のＰＣ内部に構築されるか、あるいは複数のＰＣにネットワークシステムとして構築されるかによらず有効である。

本ソフトウェア評価システムを搭載するコンピュータには、ＣＰＵ１、チップセット２、ＲＡＭ３、ハードディスクコントローラ４、ディスプレイコントローラ５、ハードディスクドライブ６、ＣＤ−ＲＯＭドライブ７、ディスプレイ８が搭載されている。また、ＣＰＵとチップセットを繋ぐ信号線１１、チップセット２とＲＡＭ３とを繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とハードディスクドライブ６とを繋ぐ信号線１４、ハードディスクコントローラ４とＣＤ−ＲＯＭドライブ７とを繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８とを繋ぐ信号線１６が搭載されている。

＜関数処理に対する処理ログ取得＞
本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムを説明するために、まず図２によって、複数のモジュールに分かれたソフトウェアが、通常の状態でどのようにメモリにロードされるかを説明する。

通常、複数のモジュールに分かれたソフトウェアは、全体の制御を行う実行ファイルＥＸＥ（２３）と、モジュールとして存在しＥＸＥの補完的な役割を担うダイナミックリンクライブラリＤＬＬ（２７）とに分かれており、メモリにはＥＸＥとＤＬＬの両方がロードされる。ＥＸＥはコードセグメント（２８）とデータセグメント（２９）、そしてインポート関数アドレステーブル（２２）から成っている。更に、インポート関数アドレステーブルは、関数の所属するＤＬＬによって分かれており（２１, ２４）、ＤＬＬごとにそれぞれの関数がロードされたアドレスが書かれている（３０〜３５）。ＤＬＬの関数の実体は、ＤＬＬごとに分かれて（２５, ２６）ロードされ、それぞれの関数は該当するＤＬＬの一部としてロードされる（３６〜４１）。この図では、１本のＥＸＥがＡ.ＤＬＬ及びＢ.ＤＬＬの２つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はＦｕｎｃ ＡＡ, Ｆｕｎｃ ＡＢ, Ｆｕｎｃ ＡＣ, Ｆｕｎｃ ＢＡ, Ｆｕｎｃ ＢＢ, Ｆｕｎｃ ＢＣの６個となっている。

ＥＸＥのコードセグメント内にあるコードが関数Ｆｕｎｃ ＡＡを呼び出す場合には、まずインポート関数アドレステーブル内に書かれたＦｕｎｃ ＡＡのアドレス（３０）が読み込まれる。ここには実際にはＡ.ＤＬＬの一部として読み込まれたＦｕｎｃ ＡＡコード（３６）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＡ.ＤＬＬのＦｕｎｃ ＡＡを呼び出すことができる。

図３は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してＩＡＴ Ｐａｔｃｈ（Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている。

ログ取得が開始されると、メモリ内にはＩＡＴ Ｐａｔｃｈ用のＤＬＬであるＣ.ＤＬＬ（５８）がロードされる。Ｃ.ＤＬＬはインポート関数アドレステーブル（５２）内に書かれた関数のアドレスを、Ｃ.ＤＬＬ内のログ取得コードであるＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのアドレスに書き換える（６１〜６６）。Ｃ.ＤＬＬ内のＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのコード（７３〜７８）は、ログを記録すると共に、元々の関数呼び出しを行うべくメモリにロードされている、該当する関数であるＦｕｎｃ ＡＡ, Ｆｕｎｃ ＡＢ, Ｆｕｎｃ ＡＣ, Ｆｕｎｃ ＢＡ, Ｆｕｎｃ ＢＢ, Ｆｕｎｃ ＢＣ（６７〜７２）を呼び出す。

図４Ａは、図３におけるＩＡＴ Ｐａｔｃｈの処理をあらわす図、図４Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＡ.ＤＬＬ内のＦｕｎｃ ＡＡを呼び出す際に、ＩＡＴ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。

ＥＸＥ（図４Ａの９１）がＦｕｎｃ ＡＡをコールすると（図４Ａの９４）、Ｃ.ＤＬＬ内にあるログ取得コードがＤＬＬ名／関数名をメモリに保存し（図４ＢのステップＳ４０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図４Ａの９５、図４ＢのステップＳ４０３）。その後Ｃ.ＤＬＬは本来呼び出されるはずであった、Ａ.ＤＬＬ（図４Ａの９３）内のＦｕｎｃ ＡＡをコールする（図４Ａの９６、図４ＢのステップＳ４０４）。Ａ.ＤＬＬのＦｕｎｃ ＡＡ処理（図４Ａの９７）が終了し、Ｃ.ＤＬＬに制御がリターンすると（図４Ａの９８）、Ｃ.ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図４Ａの９９）。その後、Ｃ.ＤＬＬは保存したログ情報をファイルに書き込み（図４Ａの１００、図４ＢのステップＳ４０５）、あたかもＡ.ＤＬＬのＦｕｎｃ ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（１０１）。

図５は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のＥＸＥ（１１３）が、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）内の関数を呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１１４）、処理ログを生成している（１１５）。ＡＰＩトレーサは、ＤＬＬ−１やＤＬＬ−２の関数定義を記述したファイル（１１１）と、どのＤＬＬのどの関数のインポート関数テーブルを書き換えてログを取得するかの設定シナリオ（トレースシナリオ１１２）を元に動作する。

＜メソッド処理に対する処理ログ取得＞
次に、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、実行ファイルＥＸＥ（１１８）がＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）サーバでエクスポートされているインターフェースのインスタンス作成時に、どのようにメモリにロードされるかを説明するために、まず、図６によって、通常の状態でどのようにメモリにロードされるかを説明する。

通常、インターフェースのインスタンス作成を行うと、ＣＯＭサーバ内で、要求されたインターフェース（１２１, １２２）と、そのメソッド（オブジェクト指向プログラミングにおいて、オブジェクトの実行する手続きを記述したプログラム、１３０〜１３５）が作成され、それらは、メモリ上に両方がロードされる。ここで、ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（仮想アドレステーブル）は作成された各インターフェース毎に作られ（１１８, １２０）、作成要求を行ったＥＸＥに渡される。このｖｉｒｔｕａｌ ａｄｄｒｅｓ ｔａｂｌｅには各メソッドの作成されたアドレスが書かれている（１２４〜１２９）。ＥＸＥはこれら情報を利用し、各インターフェースに対して呼び出しを行う。この図では、１本のＥＸＥがＩｎｔｅｒｆａｃｅ Ａ及びＩｎｔｅｒｆａｃｅ Ｂの２つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Ｍｅｔｈｏｄ ＡＡ, Ｍｅｔｈｏｄ ＡＢ, Ｍｅｔｈｏｄ ＡＣ, Ｍｅｔｈｏｄ ＢＡ, Ｍｅｔｈｏｄ ＢＢ, Ｍｅｔｈｏｄ ＢＣとなっている。

ＥＸＥのコードが関数Ｍｅｔｈｏｄ ＡＡを呼び出す場合には、まずｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ内に書かれたＭｅｔｈｏｄ ＡＡのアドレス（１２４）が読み込まれる。ここには実際にはＣＯＭサーバのＩｎｔｅｒｆａｃｅ Ａの一部として作成されたＭｅｔｈｏｄ ＡＡコード（１３０）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄ ＡＡを呼び出すことができる。

図７は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図６とは、ログ取得用のコードに対してＶＴａｂｌｅ Ｐａｔｃｈ（ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、メソッド呼び出しをリダイレクトしているという点で異なっている。

ログ取得が開始されると、メモリ内にはＶＴａｂｌｅ Ｐａｔｃｈ用のＤＬＬ（１４３）がロードされる。このＤＬＬはｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（１３６, １３８）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ Ａ'Ａ, Ｍｅｔｈｏｄ Ａ'Ｂ, Ｍｅｔｈｏｄ Ａ'Ｃ, Ｍｅｔｈｏｄ Ｂ'Ａ, Ｍｅｔｈｏｄ Ｂ'Ｂ, Ｍｅｔｈｏｄ Ｂ'Ｃのアドレスに書き換える（１４５〜１５０）。ＤＬＬ内のＭｅｔｈｏｄ Ａ'Ａ, Ｍｅｔｈｏｄ Ａ'Ｂ, Ｍｅｔｈｏｄ Ａ'Ｃ, Ｍｅｔｈｏｄ Ｂ'Ａ, Ｍｅｔｈｏｄ Ｂ'Ｂ, Ｍｅｔｈｏｄ Ｂ'Ｃのコード（１５７〜１６２）は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるＭｅｔｈｏｄ ＡＡ, Ｍｅｔｈｏｄ ＡＢ, Ｍｅｔｈｏｄ ＡＣ, Ｍｅｔｈｏｄ ＢＡ, Ｍｅｔｈｏｄ ＢＢ, Ｍｅｔｈｏｄ ＢＣ（１５７〜１６２）を呼び出す。

図８Ａは、図７におけるＶＴａｂｌｅ Ｐａｔｃｈの処理をあらわす図、図８Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＣＯＭサーバ内のＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄ ＡＡを呼び出す際に、ＶＴａｂｌｅ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。

ＥＸＥ（図８Ａの１６３）がＭｅｔｈｏｄ ＡＡをコールすると（図８Ａの１６６）、ＤＬＬ内にあるログ取得コードがモジュール名／インターフェース名／メソッド名をメモリに保存し（図８ＢのステップＳ８０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図８Ａの１６７、図８ＢのステップＳ８０３））。その後ＤＬＬは本来呼び出されるはずであった、ＣＯＭサーバ（図８Ａの１６５）内のＭｅｔｈｏｄ ＡＡをコールする（図８Ａの１６８、図８ＢのステップＳ８０４））。ＣＯＭサーバのＭｅｔｈｏｄ ＡＡ処理（図８Ａの１６９）が終了し、ＤＬＬに制御がリターンすると（図８Ａの１７０）、ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図８Ａの１７１）。その後、ＤＬＬは保存したログ情報をファイルに書き込み（図８Ａの１７２、図８ＢのステップＳ８０５）、あたかもＣＯＭサーバのＭｅｔｈｏｄ ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（図８Ａの１７３）。

図９は、本発明の第１の実施形態にかかるソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のＥＸＥ（１７６）が、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２（１８０）内のメソッドを呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１７７）、処理ログを生成している（１７８）。ＡＰＩトレーサは、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２の関数定義を記述したファイル（１７４）と、どのＣＯＭサーバのどのインターフェースのどのメソッドのｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅを書き換えてログを取得するかの設定シナリオ（１７５）を元に動作する。

＜実施例＞
図１０は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、それぞれの関数及びメソッドのパラメータの型や、戻り値の型を指示する、関数定義ファイルの例を示す図である。ＤＬＬ／インターフェース名及び関数／メソッド名を記述し（「関数／メソッド」とは、「関数またはメソッド」の意、以下同じ）、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本実施形態にかかるログ取得方法を実現するソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。

図１１は、図１０に示した関数定義ファイルを用いて、本発明の実施形態にかかるソフトウェア評価システムで取得した、ログの一例を示す図である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻、及びその際のパラメータ／戻り値が、ログとして生成される。

以上の説明から明らかなように、本実施形態にかかるログ取得方法によれば、複数にモジュール分けされたソフトウエアの処理ログの取得において、モジュール自体に変更を加えることなく、モジュール内に用意された関数／メソッドの呼び出しをログとして記録することが可能となり、処理ログ取得のための作業負荷を低減することが可能となる。また、生成されるログは、時間順のログとして取得することができ、ログの解析が容易となるため、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。

［第２の実施形態］
以下、第２の実施形態として、クラスを持つ関数パラメータ、または構造データ型の関数パラメータを有する関数／メソッドについて説明する。該関数パラメータの元では、ＥＸＥによって呼び出される関数／メソッドについての処理ログの取得対象が、選択的に制限されることとなる。

図１２は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルを示す図である。当該関数定義ファイルで定義されている関数“ＦｕｎｃＣｏｍｐｌｅｘＳｔｒｕｃｔ”は、２種類のパラメータ“ｉｎｄｅｘ”と“ｌｐＣｌｓＬ１”とを有し、後者は、クラスを持つパラメータとして定義されている。当該関数定義ファイルは、説明の便宜上、クラスを持つ関数パラメータとして７つのレベルがあるものとし、第１から第６のレベルの“ｓｔｒｕｃｔ”はデータメンバと、次のレベルの構造を示す構造ポインタとを備え、最後のレベルの“ｓｔｒｕｃｔ”はデータメンバのみを備えているものとする。

そして、７つのネストレベルの“ｓｔｒｕｃｔ”はそれぞれ関数定義ファイルに規定されており（ｔｙｐｅｄｅｆ ｓｔｒｕｃｔ）、“ｓｔｒｕｃｔ”内には、それぞれポインタパラメータとして、ＬＰＣＬＳ＿Ｌ２、ＬＰＣＬＳ＿Ｌ３、ＬＰＣＬＳ＿Ｌ４、ＬＰＣＬＳ＿Ｌ５、ＬＰＣＬＳ＿Ｌ６ならびにＬＰＣＬＳ＿Ｌ７が定義されている。

図１３は、図１２に示すような関数が定義されている場合における、ソフトウェア評価システムのログ取得処理の流れを示すフローチャートである。

ステップＳ１３０１において処理が開始されると、ステップＳ１３０２では、ログ取得処理が初期化され、モジュール名、インタフェース名、関数／メソッド名がＨＤＤ内に保存される。ステップＳ１３０３では、パラメータが構造ポインタとして指定されているか否かを判断し、該パラメータが構造ポインタとして指定されていなかった場合には、ステップＳ１３０９に進む。第１の実施形態では、レベル選択とは無関係に他の処理が実行されたが、この場合（ステップＳ１３０３でＮｏの場合）も同じように、呼び出し時の時刻、パラメータおよび、ポインタパラメータの指すメモリ内容がＨＤＤに保存される（ステップＳ１３０９）。その後、元の関数が呼び出され（ステップＳ１３１０）、リターン時の時刻と、戻り値と、ポインタパラメータの指すメモリ内容をＨＤＤに保存する（ステップＳ１３１１）。そして、ステップＳ１３０２に戻り、ユーザにより終了指示がなされるまで、関数／メソッドの処理を繰り返す（ステップＳ１３１２）。

ステップＳ１３０３において、パラメータが構造ポインタであると判定された場合には、関数定義ファイルにおいて指定された型に基づいて、構造ポインタの指すメモリ内容を検索し、あるいは記録する（ステップＳ１３０４）。そしてステップＳ１３０５では、ｓｔｒｕｃｔのデータメンバが構造ポインタであるか否かを判定する。ｓｔｒｕｃｔのデータメンバが構造ポインタでない場合には、ステップＳ１３０９にスキップし、ステップＳ１３０９からステップＳ１３１２の処理を繰り返す。

ステップＳ１３０５において、ｓｔｒｕｃｔのデータメンバが構造ポインタであると判定された場合には、所定のレベルが設定されているか否かを判定し（ステップＳ１３０６）、所定のレベルが設定されていない場合には、ステップＳ１３０９にスキップし、ステップＳ１３０９からステップＳ１３１２の処理を繰り返す。この場合、ＥＸＥによって呼び出された全ての関数／メソッドの処理ログがステップＳ１３０９においてＨＤＤに保存される。なお、レベルが設定されていない場合には、ユーザに対して警告する処理を加えるようにしてもよいし、あるいはユーザに対して確認をとる処理を加えるようにしてもよい。ステップＳ１３０６において所定のレベルが設定されていなかった場合には、代わりに、宛先モジュールのみをオペレーティングシステムのモジュールリストに記録し、元の関数を呼び出した後、ステップＳ１３１２にスキップするようにしてもよい。あるいは、所定の処理を実行する関数を呼び出す際の所定の情報、実行結果を受け取る際の所定の情報は、受信したポインタパラメータによって生成されるメモリ内容を含んでいなくてもよい。そのような場合、構造ポインタの指すメモリ内容が保存されることはなく、あるいは出力されることもない。

ステップＳ１３０６において所定のレベルが設定されている場合には、ステップＳ１３０７において保存されるデータメンバのカンレトレベルが所定のレベルより小さい（浅い）か否かを判定する。データメンバのカレントレベルが所定のレベルと同等かそれより大きい（深い）場合には、ステップＳ１３０９に進み、ステップＳ１３０９からステップＳ１３１２の処理を繰り返す。ステップＳ１３０９では、上述のポインタパラメータにより指定されるデータメンバの上記所定のレベルまでのメモリ内容が保持されることとなる。

ステップＳ１３０７において、データメンバのカレントレベルが所定のレベルより小さい場合には、ステップＳ１３０８においてデータメンバのカレントレベルを１つインクリメントし、ステップＳ１３０４に戻り、関数／メソッドのリターン処理を実行する。ステップＳ１３０３からステップＳ１３０６の処理は戻り値を解析するのにも適している。

上述の処理を更に理解するために、ここでは、一例として図１４に示す関数についてのステップＳ１３０３からステップＳ１３０９までの処理を詳細に説明する。なお、説明にあたっては以下のように仮定する。

ステップＳ１３０７においてカレントレベルが小さいか否かを判定する際に比較される所定レベルとしては２が設定されるものとする。

トレースされる関数は、例えば、図１４に示すＦｕｎｃ（Ｓｔｒｕｃｔ＿Ａｐ＊）のような、Ｐという名称の構造ポインタパラメータを有しているものとする。

Ｓｔｒｕｃｔ＿Ａは、ＡＡ（ここでは、ＡＡは、ポインタ以外であればいかなる内容であってもよい）と構造ポインタＡｐ＊とを備え、図１４に示すようにＳｔｒｕｃｔ＿Ｂを指すものとする。

Ｓｔｒｕｃｔ＿Ｂは、データメンバＢＢと構造ポインタＢｐ＊とを備え、図１４に示すようにＳｔｒｕｃｔ＿Ｃを指すものとする。

フローチャートのステップＳ１３０３からステップＳ１３０９が実行された場合、ステップＳ１３０３では、パラメータが構造ポインタ（図１３に示すＰ）であるか否かの判定がなされる。その後、ステップＳ１３０４に進み、Ｓｔｒｕｃｔ＿Ａの内容ＡＡをメモリに保存する。ステップＳ１３０５では、Ｓｔｒｕｃｔ＿Ａのデータメンバ（Ａｐ＊）が構造ポインタであることが確認され、ステップＳ１３０６に進み、所定のレベルが設定されていることを確認した後、ステップＳ１３０７に進む。ステップＳ１３０７では、カレントレベルが所定のレベルより小さいか否かが判定される。ここではカレントレベルは１で、所定のレベル２よりも小さいため、ステップＳ１３０８に進む。ステップＳ１３０８では、カレントレベルがインクリメントされ、これによりカレントレベルは２になる。その後、ステップＳ１３０４に戻り、第２のレベルの処理を開始するとともに、メモリにＳｔｒｕｃｔ＿Ｂの内容ＢＢを保存する。ステップＳ１３０５において、Ｓｔｒｕｃｔ＿Ｂのデータメンバ（Ｂｐ＊）が、構造ポインタであることを確認した後、ステップＳ１３０６に進み、所定レベルが設定されていることを確認した後、ステップＳ１３０７に進む。ステップＳ１３０７では、カレントレベルが所定レベルより小さいか否かを判定する。ここでは、カレントレベルは２で所定レベルの２と等しいことから、ステップＳ１３０８ではなくステップＳ１３０９に進む。ステップＳ１３０９では、ステップＳ１３０４においてハードディスクに保存されたパラメータの内容ＡＡおよびＢＢを保存する。所定レベルが２であるため、この例では、内容ＣＣはハードディスクに保存されない。

上記実施例において、ステップＳ１３０７における判定がＮｏであった場合には、ステップＳ１３０９に進み、既に取り出された内容を保存する。また、ステップＳ１３０７における判定がＹｅｓであった場合には、ステップＳ１３０８に進み、カレントレベルをインクリメントする。

図１５は、本実施形態にかかるソフトウェア評価システムにおいて、メモリ内容の記録に際してデータメンバのレベルを利用しなかった場合に、図１２に示す関数定義のもとで取得されたログデータを示す図である。結果は従来と同様になる。ログデータから、全てのパラメータ情報が保存／出力されているため、全てのパラメータを出力するのに時間がかかる上、該情報を保存するために高いメモリ容量が必要となる。また、ユーザがそこまで詳細なログデータを必要としない場合もある。

一方、図１６は、本実施形態にかかるソフトウェア評価システムにおいて、メモリ内容の記録に際してデータメンバのレベルを利用した場合に、図１２に示す関数定義のもとで取得されたログデータを示す図である。この場合、所定レベルは２である。

データメンバのレベルを利用した場合（図１６）、利用しなかった場合（図１５）と比べて、ユーザが求めるパラメータ情報のみを出力することができ、その結果、ログ取得性能を向上させることができる。

なお、本発明は、最良の実施例を考慮して説明したものであり、上述の処理、特にステップＳ１３０４〜１３０６は上述の順序に限定されるものではなく、例えば、ステップＳ１３０６の処理はステップＳ１３０４の前に行われるようにしてもよいし、ステップＳ１３０８からステップＳ１３０４に戻るようにし、設定レベルが設定されているか否かの判定は、１回のみ行われるようにしてもよい。

構造ポインタのようなパラメータを記述すること自体は、本処理の特徴ではないが、当業者であれば、構造パラメータを定義したり記述するための様々な方法を提案することができ、その中には、特開２００２−１９９１１２８号公報や特開２００２−１９１１２９号公報に記載の方法も含まれる。

更に、本処理は、ログ取得に際して所定の関数を選択するための工程として、日付単位でログを記録する記録工程と、ログのサイズが所定サイズを超えた場合に新しいファイルを生成する工程と、ログの個数が所定個数を超えた場合に新しいファイルを生成する工程と、前記メモリ内のログの数が所定数を超えた場合に、メモリ内のログをディスク装置に移動し保存する工程とを備える。これらの工程の詳細は、特願２００２−１９１１２８、特願２００２−１９１１２９、特願２００２−１９１１３０、ならびに特願２００３−０９９４６５に記載されている。

［他の実施形態］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給するよう構成することによっても達成されることはいうまでもない。この場合、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することにより、上記機能が実現されることとなる。なお、この場合、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現される場合に限られない。例えば、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、前述した実施形態の機能が実現される場合も含まれる。つまり、プログラムコードがメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって実現される場合も含まれる。

本発明の第１の実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。 本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、関数ロード時の通常のメモリ構成をあらわす図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈを使用時の状態を示す図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。 本発明の第１の実施形態にかかるソフトウェア評価システムのＩＡＴ Ｐａｔｃｈを使用時の内部構成をあらわす図である。 本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、ＣＯＭサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ Ｐａｔｃｈを使用時の状態を示す図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、内部構成をあらわす図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの型や、戻り値の型を指示する、関数定義ファイルの例を示す図である。 本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。 本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、関数定義ファイルを示す図である。 関数定義ファイルが図１２に示すように規定されていた場合に、ソフトウェア評価システムを用いてログ取得するための処理の流れを示す図である。 図１３にかかるフローチャートを説明する際に用いた、ポインタパラメータを備える関数の一例を示す図である。 本発明にかかるソフトウェア評価システムにおいて、メモリ内容の記録に際してデータメンバの所定レベルをしなかった場合に、図１２に示す関数定義ファイルのもとで取得されるログデータを示す図である。 本発明にかかるソフトウェア評価システムにおいて、メモリ内容の記録に際してデータメンバの所定レベルを利用した場合に、図１２に示す関数定義ファイルのもとで取得されるログデータを示す図である。

Claims (7)

1. 所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
   ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
   前記ログ取得のための関数は、
   前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
   前記関数を呼び出す際のパラメータが構造を指すポインタを含む場合に、当該ポインタの指す構造に含まれる更に下位レベルの構造を指す更なるポインタの探索を、現在のレベルが設定レベルに達するまで繰り返し実行し、当該設定レベルに達すると終了する工程と、
   前記関数を呼び出す際のパラメータと、該パラメータが構造を指すポインタを含む場合に探索された構造のデータとを含む、前記関数を呼び出す際の情報を記録する工程と
   前記実行結果を受け取った際の情報を記録する工程と
   を備えることを特徴とするログ取得方法。
2. 前記関数を呼び出す際の情報は更に、少なくとも、呼び出された関数の関数名、呼び出す際の時刻のいずれかを備えることを特徴とする請求項１に記載のログ取得方法。
3. 前記実行結果を受け取った際の情報は、少なくとも、受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値、または受け取った際のポインタの指すメモリ内容のいずれかを備えることを特徴とする請求項１に記載のログ取得方法。
4. 前記所定の処理を行う関数のアドレスは、該関数を提供するダイナミックリンクライブラリごとに、インポート関数アドレステーブルに記載されていることを特徴とする請求項１に記載のログ取得方法。
5. 前記関数を呼び出す際の情報として、前記ポインタの指す構造を読み出す毎に記録することを特徴とする請求項１に記載のログ取得方法。
6. 請求項１乃至５に記載のログ取得方法をコンピュータによって実行させるための制御プログラム。
7. 請求項６に記載の制御プログラムを格納した記憶媒体。

Images