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

Abstract

【課題】ソフトウェアの処理ログを容易に取得でき、バグの解析のための構成を削減することが可能なログ取得方法を提供する。
【解決手段】所定の処理を実行するための少なくとも１つの関数１１６を備えるプログラム１１３の実行中のログを取得するための方法は、少なくとも１つの関数１１６のアドレスをログ取得のための関数１１４のアドレスに書き換える工程を備え、該ログ取得のための関数１１４は、少なくとも１つの関数１１６を呼び出し、所定の処理を実行させ、実行結果を受け取り、受け取った該実行結果をプログラム１１３に受け渡し、所定の方法でその形式を指定可能なポインタ・パラメータが、前記プログラムの関数定義１１１において定義されているか否かを判断し、定義されている場合には、ポインタ・パラメータにより指定されたメモリの内容を、指定されたデータ形式のデータとして記録１１５することを特徴とする。
【選択図】図５

Description

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

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

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

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

本発明は、上記課題を鑑みてなされたものであり、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能なログ取得方法、ならびに該方法をコンピュータによって実現させるためのプログラム、および該プログラムを格納した記憶媒体を提供することを目的とする。

上記の目的を達成するために本発明に係るログ取得方法は、所定の処理を行う少なくとも１つの関数を備えるプログラムの実行中のログを取得するための方法であって、
ロードされた前記所定の処理を行う少なくとも１つの関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、前記ログ取得のための関数は、前記所定の処理を行う少なくとも１つの関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記プログラム内の関数定義において、ポインタ・パラメータが所定の定義方法で定義されているか否かを判断する工程と、
ポインタ・パラメータが所定の定義方法で定義されていた場合、該定義方法に基づいて該ポインタ・パラメータの指すメモリの内容を特定のデータ形式のデータとして記録する工程とを備える。

好適には、ポインタ・パラメータの種類はインデックス構造（ｉｎｄｅｘ ｓｔｒｕｃｔｕｒｅ）により定義され、上記判断工程は当該インデックス構造の指定されたメンバーを参照することにより該ポインタ・パラメータの種類を判断する工程を備える。当該インデックス構造のメンバーの種類としては、様々な種類の非エクスポート関数を適用することができ、また様々な種類の構造を適用することができる。

本発明の好適な実施形態について、図面を参照しながら以下に詳細を説明する。

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

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

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

また、ＣＰＵ１とチップセット２を繋ぐ信号線１１、チップセット２とＲＡＭ３とを繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とハードディスクドライブ６とを繋ぐ信号線１４、ハードディスクコントローラ４とＣＤ−ＲＯＭドライブ７とを繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８とを繋ぐ信号線１６が設けられている。

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

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

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

図３は、第１の実施形態にかかるメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してＩＡＴ Ｐａｔｃｈ(Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ Ｐａｔｃｈ)という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている
ログ取得が開始されると、メモリ内にはＩＡＴ Ｐａｔｃｈ用のＤＬＬであるＣ.ＤＬＬ(５８)がロードされる。Ｃ.ＤＬＬはインポート関数アドレステーブル(５２)内に書かれた関数のアドレスを、Ｃ.ＤＬＬ内のログ取得コードであるＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのアドレス（６１〜６６）に書き換える。Ｃ.ＤＬＬ内のＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのコード(７３〜７８)は、ログを記録すると共に、元々の関数呼び出しを受けるべくメモリにロードされている、該当する関数であるＦｕｎｃ ＡＡ, Ｆｕｎｃ ＡＢ, Ｆｕｎｃ ＡＣ, Ｆｕｎｃ ＢＡ, Ｆｕｎｃ ＢＢ, Ｆｕｎｃ ＢＣ(６７〜７２)を呼び出す。

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

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

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

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

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

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

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

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

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

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

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

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

［第２の実施形態］
本実施形態では、コールバック関数等のエクスポートされていない関数をログとして取得する場合について述べる。

図１０は、本実施形態にかかるソフトウェア評価システムにおいて用いられる関数であって、従来の関数定義ではパラメータを取得することができない関数の一例を示す図である。

コールバック関数として、（例えば）ＦｕｎｃＩｎｔｅｒｎａｌ１、ＦｕｎｃＩｎｔｅｒｎａｌ２、ＦｕｎｃＩｎｔｅｒｎａｌ３、ＦｕｎｃＩｎｔｅｒｎａｌ４の４種類のコールバック関数が定義されている。ＧｅｔＦｕｎｃＰｏｉｎｔｅｒ関数の第１のパラメータであるｄｗＫｉｎｄは、第２のパラメータであるｌｐＢｕｆに送られる４種類のコールバック関数のうちの１つのポインタを示す。ＧｅｔＦｕｎｃＰｏｉｎｔｅｒ関数は、第１のパラメータが０の場合にはＦｕｎｃＩｎｔｅｒｎａｌ１のアドレスとしてｌｐＢｕｆを取り扱い、第１のパラメータが１の場合には、ＦｕｎｃＩｎｔｅｒｎａｌ２のアドレスとしてｌｐＢｕｆを取り扱い、第１のパラメータが２の場合にはＦｕｎｃＩｎｔｅｒｎａｌ３のアドレスとしてｌｐＢｕｆを取り扱う。ＧｅｔＦｕｎｃＰｏｉｎｔｅｒ関数が従来の関数定義で定義されていた場合には、ｌｐＢｕｆはｖｏｉｄ形式のポインタとなり、その結果、データが取得されることはない。

図１１は本実施形態にかかるソフトウェア評価システムにおいて、図１０に示す関数のパラメータをログ取得するためのＩＤＬによる記述である。

コールバック関数は従来の方法で定義されている。さらに、インデックス構造であるＩＮＤＥＸ＿ＳＴＲＵＣＴは呼び出される関数内において定義されている。そして、ログ取得関数において、ＧｅｔＦｕｎｃＰｏｉｎｔｅｒ関数の第２のパラメータであるｖｏｉｄ＊ｌｐＢｕｆに対して、ｃｕｓｔｕｍ（ＰＡＴ＿ＰＡＲＡＭ＿ＩＤ，“ｆｕｎｃｋｉｎｄ＿ｉｓ（ｄｗＫｉｎｄ：ＩＮＤＥＸ＿ＳＴＲＵＣＴ）”）と宣言している。これにより、ｌｐＢｕｆは、第１のパラメータであるｄｗＫｉｎｄの値に依存する、インデックス構造の異なるメンバーのデータ種類として取り扱われることとなる。つまり、第１のパラメータであるｄｗＫｉｎｄの値が０の場合にはＦｕｎｃＩｎｔｅｒｎａｌ１＊データとして、１の場合にはＦｕｎｃＩｎｔｅｒｎａｌ２＊データとして、２の場合にはＦｕｎｃＩｎｔｅｒｎａｌ３＊データとして、３の場合にはＦｕｎｃＩｎｔｅｒｎａｌ４＊データとして、取り扱われ、ログとして保存される。

図１２は、本実施形態にかかるソフトウェア評価システムにおいて、図１１の様に関数定義されている場合のログ取得の流れを示す図である。

処理が開始されると（ステップＳ５２０１）、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をＨＤＤに保存する(ステップＳ５２０２)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する(ステップＳ５２０３)。そして、関数定義にバイナリ取得の設定が存在するか判別し(ステップＳ５２０４)、存在する場合には、保存するメモリサイズを各定義方法(binid_is, size_is, length_is, bytes_is)毎に計算する(ステップＳ５２０５)。その後、ｆｕｎｃｋｉｎｄにて定義された値が保存され、生成されたログ取得コードのアドレスにより書き換えられる（ステップＳ５２０６）。

続いて、元の関数を呼び出す(ステップＳ５２０７)。関数からリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する(ステップＳ５２０８)。続いて、関数定義におてｆｕｎｃｋｉｎｄの設定がなされているか否かを判断する（ステップＳ５２０９）。設定されている場合には、ｆｕｎｃｋｉｎｄ＿ｉｓに定義された関数定義は、関数定義ファイルから取得され、ログ取得コードは当該定義に基づいて生成される（ステップＳ５２１０）。続いて、ｆｕｎｃｋｉｎｄ＿ｉｓに定義された値が保存され、生成されたログ取得コードのアドレスにより書き換えられる（ステップＳ５２１１）。ユーザによって終了コマンドを入力されると処理を終了する（ステップＳ５２１２）。

ｆｕｎｃｋｉｎｄ＿ｉｓによって設定されたパラメータが、生成されたログ取得コードのアドレスによって書き換えられた場合、当該アドレスをもって呼び出された元の関数は従来のログと同様の方法で処理される。すなわち、生成されたログ取得コードは非エクスポート関数を呼び出し、処理を実行し、受け取った実行結果を送信する一方、非エクスポート関数を呼び出す際に指定の情報を保存し、実行結果をログとして受信した際に指定の情報を保存する。

図１３は、本実施形態における定義として図１１に図示の定義を用いて取得されたログデータを示す図である。コールバック関数や非エクスポートインターナル関数を取得するための設定は関数定義ファイルにおいてなされるため、ＦｕｎｃＩｎｔｅｒｎａｌ１、ＦｕｎｃＩｎｔｅｒｎａｌ４のような、非エクスポート関数のログが取得されうる。

このように、本実施形態によれば、従来の方法では取得されることのない非エクスポート関数のログを取得することが可能となる。

［第３の実施形態］
図１４は第３の実施形態にかかるソフトウェア評価システムにおいて用いられ、従来の関数定義ではパラメータは取得することができない関数の一例を示す図である。

ＳＴＲＵＣＴＫＩＮＤ１、ＳＴＲＵＣＴＫＩＮＤ２、ＳＴＲＵＣＴＫＩＮＤ３の３つの構造体が定義されている。ＦｕｎｃＧｅｔＤａｔａ関数の第１のパラメータであるｄｗＫｉｎｄは、当該第２のパラメータｌｐＢｕｆに送信される３つの構造体のうちの１つのポインタを表わしている。第１のパラメータが１の場合、ＦｕｎｃＧｅｔＤａｔａ関数はｌｐＢｕｆをＳＴＲＵＣＴＫＩＮＤ１に対するポインタとして取り扱い、第１のパラメータが２の場合、ＳＴＲＵＣＴＫＩＮＤ２に対するポインタとして取り扱い、第１のパラメータが３の場合、ＳＴＲＵＣＴＫＩＮＤ３に対するポインタとして取り扱う。ＦｕｎｃＧｅｔＤａｔａが従来の関数定義で定義されていた場合には、ｌｐＢｕｆはｖｏｉｄ形式のポインタとなり、その結果、データが取得されることはない。

図１５はＳＴＲＵＣＴＫＩＮＤ１、ＳＴＲＵＣＴＫＩＮＤ２、ＳＴＲＵＣＴＫＩＮＤ３のそれぞれの構造体によってどのようにメモリが使用されるかを示した図である。

ＳＴＲＵＣＴＫＩＮＤ１（３３０）は、メンバーとして、０ｘ００００にｃｈａｒ ｃｈＰａｒａｍ（３３１）を、０ｘ０００１にＤＷＯＲＤ ｄｗＰａｒａｍ（３３２）を、０ｘ０００５にｓｈｏｒｔ ｓｈＰａｒａｍ（３３３）を有している。構造体ＳＴＲＵＣＴＫＩＮＤ２（３３４）はメンバーとして、０ｘ００００にｓｈｏｒｔ ｓｈＰａｒａｍ（３３５）を、０ｘ０００２にＤＷＯＲＤ ｄｗＰａｒａｍ（３３６）を、０ｘ０００６にｃｈａｒ ｃｈＰａｒａｍ（３３７）を有している。構造体ＳＴＲＵＣＴＫＩＮＤ３（３３８）はメンバーとして、０ｘ００００にｃｈａｒ ｃｈＰａｒａｍ（３３９）を、０ｘ０００１にｓｈｏｒｔ ｓｈＰａｒａｍ（３４０）を、０ｘ０００３にＤＷＯＲＤ ｄｗＰａｒａｍ（３４１）を、０ｘ０００７にｌｏｎｇ ｌＰａｒａｍ（３４２）を、０ｘ０００Ｂにｉｎｔ ｎＰａｒａｍを有している。

当該構造体はサイズ情報を含んでおらず、構造体データのためのメモリ構成は構造体ごとに異なる。このため、従来の方法では利用されなかった。

図１６は、本実施形態にかかるソフトウェア評価システムにおいて、図１４に志hめす関数のパラメータのログを取得するためのＩＤＬによる記述である。

構造体は従来の方法で定義されている。さらに、インデックス構造であるＩＮＤＥＸ＿ＳＴＲＵＣＴは呼び出される関数内において定義されている。そして、ログ取得関数において、ＦｕｎｃＧｅｔＤａｔａ関数の第２のパラメータであるｖｏｉｄ＊ｌｐＢｕｆに対して、ｃｕｓｔｕｍ（ＰＡＴ＿ＰＡＲＡＭ＿ＩＤ，“ｓｔｒｕｃｔｋｉｎｄ＿ｉｓ（ｄｗＫｉｎｄ：ＩＮＤＥＸ＿ＳＴＲＵＣＴ）”）と宣言している。これにより、ｌｐＢｕｆは、第１のパラメータであるｄｗＫｉｎｄの値に依存する、インデックス構造の異なるメンバーのデータ種類として取り扱われることとなる。つまり、第１のパラメータであるｄｗＫｉｎｄの値が１の場合にはＳＴＲＵＣＴＫＩＮＤ１＊データとして、２の場合にはＳＴＲＵＣＴＫＩＮＤ２＊データとして、３の場合にはＳＴＲＵＣＴＫＩＮＤ３＊データとして取り扱われ、ログとして保存される。

図１７は、本実施形態にかかるソフトウェア評価システムにおいて、図１６の様に関数定義されている場合のログ取得の流れを示す図である。

処理が開始されると（ステップＳ５７０１）、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をＨＤＤに保存する（ステップＳ５７０２）。次に関数定義に構造体の種類の設定がなされているか否かを判別する（ステップＳ５７０４）。そして、呼び出し時刻、パラメータおよびポインタ・パラメータによって指定されたメモリの位置に記載された内容をメモリに保存する（ステップＳ５７０５）。その後、元の関数が呼び出される（ステップＳ５７０６）。関数からリターンすると、関数定義内に構造体の種類（ｓｔｒｕｃｔｋｉｎｄ＿ｉｓ）が設定されているか否かが判別される（ステップＳ５７０７）。設定されている場合には、当該設定された構造体パラメータのデータが構造体の種類（ｓｔｒｕｃｔｋｉｎｄ＿ｉｓ）において定義されたデータ種類として解析される。そして、リターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ５７０９）。そして、ユーザによって終了コマンドが入力されると処理を終了する（ステップＳ５７１０）。

図１８は、本実施形態における定義として図１６に図示の定義を用いて取得されたログデータを示す図である。ｖｏｉｄ＊の構造体上のデータであって、通常の関数定義によりポインタのみを取得可能なデータが、使用される構造体の種類に応じてログとして取得されうる。

このように、第３の実施形態によれば、従来の方法では取得することができなかったパラメータのログを取得することが可能となる。

［第４の実施形態］
本実施形態では、ログ取得のための各種設定を行うユーザインターフェースと、該ユーザインターフェースで設定された情報に基づいて行われる処理について説明する。図１９は、第４の実施形態にかかるログ取得を開始する関数／メソッドを設定するためのユーザインターフェースである。

ユーザインターフェースには、ログ取得対象となっているモジュール／インターフェース(３５０)から、どのモジュール／インターフェースを設定するかを選択するドロップダウンリスト(３５２,３５３)と、そこで選択したモジュール／インターフェースでエクスポートされている関数／メソッド(３５１)から、どの関数／メソッドをログ取得開始トリガーとして設定するかを選択するドロップダウンリスト(３５４,３５５)とを備える。

図２０は、第４の実施形態にかかるソフトウェア評価システムで、図１９で設定した内容に従い、ログを取得する場合の流れを示す図である。

処理が開始されると(ステップＳ３４０１)、ログ取得コードは呼び出された関数／メソッドがログ取得開始トリガーとして設定されているか判別する(ステップＳ３４０２)。ログ取得開始トリガーと一致した場合には、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をＨＤＤに保存する(ステップＳ３４０３)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存し(ステップＳ３４０４)、元の関数／メソッドを呼び出す(ステップＳ３４０５)。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する(ステップＳ３４０６)。この処理はユーザから終了の命令があるまで(ステップＳ３４０７)続行されるが、その際には、ログ取得開始トリガーの判別を行わない。

以上の説明から明らかなように、本実施形態によれば、ログ取得を行う関数／メソッドを任意に選択できるようにすることで、ログの解析が容易になるという効果がもたらされる。

［第５の実施形態］
上記第４の実施形態では、ログを取得する関数／メソッドをユーザが任意に選択可能としたが、本実施形態では、ログ取得を停止する関数／メソッドを任意に選択可能とする。

図２１は、本実施形態にかかるログ取得を停止する関数／メソッドを設定するためのユーザインターフェースである。

ユーザインターフェースには、ログ取得対象となっているモジュール／インターフェース(３５６)から、どのモジュール／インターフェースを設定するかを選択するドロップダウンリスト(３５８,３５９)と、そこで選択したモジュール／インターフェースでエクスポートされている関数／メソッド(３５７)から、どの関数／メソッドをログ取得停止トリガーとして設定するかを選択するドロップダウンリスト(３６０,３６１)とを備える。

図２２は、本実施形態にかかるソフトウェア評価システムで、図２１で設定した内容に従い、ログを取得する場合の流れを示す図である。

処理が開始されると(ステップＳ３６０１)、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をＨＤＤに保存する(ステップＳ３６０２)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存し(ステップＳ３６０３)、元の関数／メソッドを呼び出す(ステップＳ３６０４)。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する(ステップＳ３６０５)。その後呼び出された関数／メソッドがログ取得停止トリガーとして設定されているか判別する(ステップＳ３６０６)。ログ取得停止トリガーと一致した場合には、ログ取得処理は終了する(ステップＳ３６０７)。また、ログ取得停止トリガーと一致しない場合でも、この処理はユーザから終了の命令があると(ステップＳ３６０６)終了される。これにより、任意に設定した関数／メソッドのログ取得を停止することができることとなり、ユーザの求めるログのみを取得できるため、ログの解析が容易になるという効果がもたらされる。

［第６の実施形態］
上記第４および第５の実施形態において述べたユーザインタフェースでは、ユーザが選択した任意の関数／メソッドでログの取得開始／停止をユーザが任意に選択することとしたが、ユーザが選択した任意の関数／メソッドが、エラーで終了した場合のみ、ログの取得開始／停止をするように設定することも可能である。

図２３は、本実施形態にかかるログ取得を開始／停止するための関数／メソッドを設定するためのユーザインターフェースに、エラーで終了した場合のみトリガー機能（ログ取得開始／停止機能）を使用する設定を追加したものである。本ユーザインターフェースは、図１９及び、図２１双方に適応することが可能である。

ユーザインターフェースには、ログ取得対象となっているモジュール／インターフェース(３６２)から、どのモジュール／インターフェースを設定するかを選択するドロップダウンリスト(３６４, ３６５)と、そこで選択したモジュール／インターフェースでエクスポートされている関数／メソッド(３６３)から、どの関数／メソッドをトリガーとして設定するかを選択するドロップダウンリスト(３６６, ３６７)と、関数／メソッドがエラーで終了した場合のみトリガー機能を有効にする為のチェックボックス（３６８）とを備える。

図２４は、本実施形態にかかる関数／メソッドのエラー定義の内容を示したものである。本実施形態においてはエラー定義がファイルとなっており、ファイルには各関数／メソッドのパラメータ及び戻り値とそのエラー条件等が定義され記されている。

図２５は、本実施形態にかかるソフトウェア評価システムの、ログを取得する場合の流れを示す図であり、図２３で設定した内容に従い、ログ取得開始と、エラー時のみトリガーを使用する機能を併用して設定した場合である。

処理が開始されると(ステップＳ３９０１)、ログ取得コードは呼び出された関数／メソッドがログ取得開始トリガーとして設定されているか判別する(ステップＳ３９０２)。ログ取得開始トリガーとして設定されている場合には、モジュール名、インターフェース名、関数／メソッド名をメモリに一時的に保存する(ステップＳ３９０３)。

次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をメモリに一時的に保存し(ステップＳ３９０４)、元の関数／メソッドを呼び出す(ステップＳ３９０５)。メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をメモリに一時的に保存する(ステップＳ３９０６)。

次にログ取得開始トリガーがエラーでのみ使用するかどうかを判別し(ステップＳ３９０７)、そうであれば、関数／メソッドがエラーであるかを判別する(ステップＳ３９０８)。もし、エラーでない場合には、一時メモリに保存したログを破棄し(ステップＳ３９０９)、処理のはじめに戻る。関数／メソッドがエラーであった場合には、一時メモリに保存したログをＨＤＤに保存し(ステップＳ３９１０)、通常のログ取得処理を引き続き行う(ステップＳ３９１１)。この処理はユーザから終了の命令があるまで(ステップＳ３９１２)続行される。

図２６は、図２５のステップＳ３９１１で示した通常のログ取得処理の詳細の流れを示す図である。

処理が開始されると(ステップＳ４００１)、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をＨＤＤに保存する(ステップＳ４００２)。
次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存し(ステップＳ４００３)、元の関数／メソッドを呼び出す(ステップＳ４００４)。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する(ステップＳ４００５)。

図２７は、本実施形態にかかるソフトウェア評価システムの、ログを取得する場合の流れを示す図であり、図２３で設定した内容に従い、ログ取得停止と、エラー時のみトリガーを使用する機能とを併用して設定した場合である。

処理が開始されると(ステップＳ４１０１)、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をＨＤＤに保存する(ステップＳ４１０２)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存し(ステップＳ４１０３)、元の関数／メソッドを呼び出す(ステップＳ４１０４)。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する(ステップＳ４１０５)。その後呼び出された関数／メソッドがログ取得停止トリガーとして設定されているか判別する(ステップＳ４１０６)。ログ取得停止トリガーと一致した場合には、次にログ取得停止トリガーがエラーでのみ使用するかどうかを判別し(ステップＳ４１０７)、そうであれば、関数／メソッドがエラーであるかを判別する(ステップＳ４１０８)。もし、エラーである場合は、ログ取得処理は終了する(ステップＳ４１０９)。また、この処理はユーザから終了の命令があると(ステップＳ４１１０)終了される。

これにより、任意の関数／メソッドでエラーが発生した場合からログの取得を開始したり、停止したりすることが可能ととなり、ユーザの求めるログを取得することが可能になり、ログの解析が容易になるという効果がもたらされる。

［第７の実施形態］
上記第４乃至第６の実施形態におけるユーザインターフェースは、選択可能な関数／メソッドが所定の順序で配列されているにすぎなかったが、インターフェース、メソッドの関係が容易に把握できるようなツリー表示としてもよい。

図２８は、本発明の第７の実施形態にかかるインターフェースとメソッドのツリー表示を行うユーザインターフェースを示す図である。

ユーザインターフェースには、インターフェース及びメソッドをツリー表示する為のビュー(３８０)が備えられている。ユーザがインターフェースＩｎｔｅｒｆａｃｅＡ(３８１)をチェックすることで、そのインターフェース内の全てのメソッドＭｅｔｈｏｄＡＡ, ＭｅｔｈｏｄＡＢ, ＭｅｔｈｏｄＡＣ(３８２〜３８４)は全て選択され、ログの取得対象となる。また、インターフェースＩｎｔｅｒｆａｃｅＢ(３８５)のチェックを外すことで、そのインターフェース内の全てのメソッドＭｅｔｈｏｄＢＡ, ＭｅｔｈｏｄＢＢ, ＭｅｔｈｏｄＢＣ(３８５〜３８８)は全て選択解除され、ログの取得対象外となる。

図２９は、本実施形態にかかるソフトウェア評価システムの、図２８のようにログ取得対象を選択した場合の、ログを取得する際の処理の流れを示す図である。

処理が開始されると(ステップＳ４３０１)、ログ取得コードはインターフェースの何らかのメソッド呼び出しが行われるたびに、そのメソッドのインターフェースが、ログ取得対象となっているかを判別する(ステップＳ４３０２)。ログ取得対象となっていた場合には、モジュール名とインターフェース、メソッド名をＨＤＤに保存する(ステップＳ４３０３)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存し(ステップＳ４３０４)、元のメソッドを呼び出す(ステップＳ４３０５)。メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する(ステップＳ４３０６)。この処理はユーザから終了の命令があるまで(ステップＳ４３０７)続行される。これにより、インターフェース、メソッドの関係を更に簡便に知ることができ、また、ログを取得したいインターフェースを容易に選択可能となり、ユーザの、求めるログを取得する方法が簡単になる。

［第８の実施形態］
上記第４乃至第７の実施形態では、任意のメソッドを選択するにあたり、インターフェース単位で選択を行うこととしたが、さらに、メソッド単位で選択を行うことも可能である。

図３０は、本実施形態にかかるインターフェースとメソッドのツリー表示を行うユーザインターフェースに関するものであり、図２８と同様であるが、選択方法が異なっている。

ユーザインターフェースには、インターフェース及びメソッドをツリー表示する為のビュー(３８９)が備えられている。ユーザがメソッドＭｅｔｈｏｄＡＡ(３９１), ＭｅｔｈｏｄＡＣ(３９３), ＭｅｔｈｏｄＢＡ(３９５)をチェックし、ＭｅｔｈｏｄＡＢ(３９２), ＭｅｔｈｏｄＢＢ(３９６), ＭｅｔｈｏｄＢＣ(３９７)のチェックを外すことで、インターフェースＩｎｔｅｒｆａｃｅＡ(２１０), ＩｎｔｅｒｆａｃｅＢ(３９４)内の全てのメソッドではなく、各インターフェースのチェックしたメソッドのみをログの取得対象とすることが可能となる。

図３１は、本実施形態にかかるソフトウェア評価システムの、図３０のようにログ取得対象を選択した場合の、ログを取得する際の処理の流れを示す図である。

処理が開始されると(ステップＳ４５０１)、ログ取得コードはインターフェースの何らかのメソッド呼び出しが行われるたびに、そのインターフェースのメソッドが、ログ取得対象となっているかを判別する(ステップＳ４５０２)。ログ取得対象となっていた場合には、モジュール名とインターフェース、メソッド名をＨＤＤに保存する(ステップＳ４５０３)。以下の処理（ステップＳ４５０４〜Ｓ４５０７）は第７の実施形態における図３３と同様である。

これにより、インターフェース毎という大きな範囲ではなく、ログを取得したいメソッドをメソッド単位でそれぞれ容易に選択可能となり、ユーザの求めるログを簡単に取得することができるという効果がもたらされる。

［第９の実施形態］
上記実施形態においては、取得したログをＨＤＤの任意の場所に保存していたが、ログの解析を容易に行うことができるよう、日付ごとに保存するようにしてもよい。

図３２は、日付毎にログを分割保存する場合の処理の流れを示す図である。

処理が開始されると(ステップＳ４６０１)、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をメモリに保存する(ステップＳ４６０２)。

次にログ取得コードは、呼び出し時の日付・時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をメモリに保存し(ステップＳ４６０３)、元の関数／メソッドを呼び出す(ステップＳ４６０４)。関数／メソッドからリターンすると、ログ取得コードはリターン時の日付・時刻、戻り値及びポインタ・パラメータの指すメモリの内容をメモリに保存する(ステップＳ４６０５)。その後呼び出された関数／メソッドのリターン時の日付が、前回に保存したログのリターン時の日付と異なるかを判別する(ステップＳ４６０６)。日付が異なる場合には、新規のログファイルを作成し、ログをそのファイルに保存する(ステップＳ４６０７)、同じ場合には、従来のログファイルにログを保存する(ステップＳ４６０８)。この処理はユーザから終了の命令があると(ステップＳ４６０９)終了される（ステップＳ４６１０）。

これにより、ユーザは求めるログを日付毎に取得することができ、ログの解析が容易になるという効果がもたらされる。

［第１０の実施形態］
上記第９の実施形態では、日付ごとにログを保存する場合について述べたが、サイズ毎もしくは個数毎にログを分割して保存するようにしてもよい。

図３３は、サイズ毎もしくは個数毎にログを分割保存する場合の処理の流れを示す図である。

処理が開始されると(ステップＳ４７０１)、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をメモリに保存する(ステップＳ４７０２)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をメモリに保存し(ステップＳ４７０３)、元の関数／メソッドを呼び出す(ステップＳ４７０４)。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をメモリに保存する(ステップＳ４７０５)。その後新規のログデータを従来のログファイルに保存した場合に、ファイルのサイズが一定値を超えるかもしくはログが一定の個数を超えるかどうかを判別する(ステップＳ４７０６)。

ある一定サイズを超えてしまう場合もしくはある一定の個数を超えてしまう場合には、新規のログファイルを作成し、ログをそのファイルに保存する(ステップＳ４７０７)、超えない場合には、従来のログファイルにログを保存する(ステップＳ４７０８)。新規のログファイルを作成した場合には、リングバッファを使用する場合で且つ、作成したログファイルの数が２個より多いかどうかを判別する(ステップＳ４７０９)。もし、条件に当てはまる場合には、最も古いログファイルを削除する(ステップＳ４７１０)。この処理はユーザから終了の命令があると(ステップＳ４７１１)終了される（ステップＳ４７１２）。

これにより、ユーザは複数作成される各ログを、一定サイズ以内や、一定個数毎で取得ができ、取り扱いが容易になる。また、リングバッファを使用することで、本ソフトウェア評価システムがＰＣのリソースに対して与える負荷を一定に抑えることが可能になり、安定したログの取得を行えるようになる。

［第１１の実施形態］
図３４は、取得したログを一定数だけメモリに保存する場合のメモリの概要図である。

一定数のログを保存するためのログ格納メモリ領域がｎ個存在し(３９８)、各ログ格納メモリ領域には、１回分の関数／メソッドのログが格納され、その情報はモジュール名、インターフェース名、関数／メソッド名、呼び出し時の時刻、呼び出し時のパラメータデータ、終了時の時刻、終了時のパラメータデータ、戻り値データ等が格納され(３９９)、可変サイズとなる。このメモリ領域には、ログ格納メモリ領域１から順にログデータは格納されていき、ログ格納メモリ領域ｎまで、使用し終わると、再度、ログ格納メモリ領域１から上書きしてログを格納する。

図３５は、取得したログを一定数だけメモリに保存する場合のログ取得の流れを示す図である。

処理が開始されると(ステップＳ４９０１)、ログ格納メモリ領域の場所を示す変数ｘを１に初期化する(ステップＳ４９０２)。そして、ログ取得を開始し、モジュール名、インターフェース名、関数／メソッド名をログ格納メモリ領域ｘに保存する(ステップＳ４９０３)。

次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をログ格納メモリ領域ｘに保存し(ステップＳ４９０４)、元の関数／メソッドを呼び出す(ステップＳ４９０５)。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をログ格納メモリ領域ｘに保存する(ステップＳ４９０６)。

その後ログ格納メモリ領域の場所を示す変数ｘに１を加算し(ステップＳ４９０７)、ｘがログ格納メモリ領域数のｎより大きいかを判別する(ステップＳ４９０８)。

ｘがｎより大きい場合にはｘに１を代入し、ログ格納メモリ領域の先頭から再度使用するように設定する(ステップＳ４９０９)。その後、リングバッファを使用するかを判別し(ステップＳ４９１０)、使用しない場合には、メモリ上に有る、全てのログデータをログファイルに保存し(ステップＳ４９１１)、メモリ上のログデータを全て削除する(ステップＳ４９１２)。この処理はユーザから終了の命令があると(ステップＳ４９１３)終了される（ステップＳ４９１４）。

これにより、メモリの使用量をある程度の値でとどめることが可能となり、本ソフトウェア評価システムがＰＣのリソースに対して与える負荷を抑えることが可能になり、安定したログの取得を行えるようになる。

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

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

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

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

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

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

以上説明したように本発明によれば、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。

本発明の実施形態とは異なる実施形態であっても、本発明の思想や目的の範囲内において実現されうるならば、本発明は特許請求の範囲に定義された場合を除き、特定の実施形態に限定されるものではない。

第１の実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。 図２は、第１の実施形態にかかる関数ロード時の通常のメモリ構成をあらわす図である。 図３は、第１の実施形態にかかるＩＡＴ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。 図４Ａは、第１の実施形態にかかるＩＡＴ Ｐａｔｃｈを使用時の状態を示す図である。 図４Ｂは、第１の実施形態にかかるログ取得処理の流れを示す図である。 図５は、第１の実施形態にかかるＩＡＴ Ｐａｔｃｈを使用時の内部構成をあらわす図である。 図６は、第１の実施形態にかかるＣＯＭサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。 図７は、第１の実施形態にかかるＶＴａｂｌｅ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。 図８Ａは、第１の実施形態にかかるＶＴａｂｌｅ Ｐａｔｃｈを使用時の状態を示す図である。 図８Ｂは、第１の実施形態にかかるログ取得処理の流れを示す図である。 図９は、第１の実施形態にかかるソフトウェア評価システムの、内部構成をあらわす図である。 図１０は、第２の実施形態にかかる関数定義の一例を示す図である。 図１１は、第２の実施形態に於いて、ポインタ・パラメータのデータの実体をログとして取得する為のＩＤＬによる記述を示す図である。 図１２は、第２の実施形態にかかるログを取得する場合の流れを示す図である。 図１３は、第２の実施形態において取得されたログデータの図である。 図１４は、第３の実施形態にかかる通常の関数定義によりパラメータを取得することができない関数の一例を示す図である。 図１５は、構造体がメモリ内においてどのように記載されたかを示す図である。 図１６は、第３の実施形態における、図１４に示す関数パラメータのログを取得するためのＩＤＬによる記述を示す図である。 図１７は、第３の実施形態における、ログ取得の処理の流れを示すフローチャートである。 第３の実施形態にかかるソフトウェア評価システムにおいて、図１６の定義により取得されたログデータの図である。 第４の実施形態で、ログ取得を開始する関数／メソッドを設定するためのユーザインターフェースを示す図である。 第４の実施形態にかかるログを取得する場合の流れを示す図である。 第５の実施形態にかかるログ取得を停止する関数／メソッドを設定するためのユーザインターフェースを示す図である。 第５の実施形態にかかるログを取得する場合の流れを示す図である。 第６の実施形態にかかるエラーで終了した場合のみトリガー機能を使用する設定を追加したユーザインターフェースを示す図である。 第６の実施形態にかかる関数／メソッドのエラー定義の内容を示した図である。 第６の実施形態にかかるログを取得する場合の流れを示す図である。 第６の実施形態にかかる通常のログ取得処理の詳細の流れを示す図である。 第６の実施形態にかかるログを取得する場合の流れを示す図である。 第７の実施形態にかかるインターフェースとメソッドのツリー表示を行うユーザインターフェースを示す図である。 第７の実施形態にかかるログを取得する際の処理の流れを示す図である。 第８の実施形態にかかるインターフェースとメソッドのツリー表示を行うユーザインターフェースを示す図である。 第８の実施形態にかかるログを取得する際の処理の流れを示す図である。 第９の実施形態にかかる日付毎にログを分割保存する場合の処理の流れを示す図である。 第１０の実施形態にかかるサイズ毎もしくは個数毎にログを分割保存する場合の処理の流れを示す図である。 第１１の実施形態において、取得したログを一定数だけメモリに保存する場合のメモリの概要図である。 第１１の実施形態において、取得したログを一定数だけメモリに保存する場合のログ取得の流れを示す図である。

Claims (21)

1. 所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
   ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
   前記ログ取得のための関数は、
   前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
   前記プログラム内の関数定義において、ポインタ・パラメータが所定の定義方法で定義されているか否かを判断する工程と、
   ポインタ・パラメータが所定の定義方法で定義されていた場合、該定義方法に基づいて該ポインタ・パラメータの指すメモリの内容をログとして記録する工程と
   を備えることを特徴とするログ取得方法。
2. 前記ポインタ・パラメータの種類は、インデックス構造体により定義され、前記判断する工程は、当該インデックス構造体の指定されたメンバーを参照することにより、当該ポインタ・パラメータの種類を判断する工程を含むことを特徴とする請求項１に記載のログ取得方法。
3. 前記インデックス構造体のメンバーのうちの少なくともいくつかは、様々な種類の非エクスポート関数であることを特徴とする請求項２に記載のログ取得方法。
4. 前記インデックス構造体のメンバーの少なくともいくつかは、様々な種類の構造体であることを特徴とする請求項２に記載のログ取得方法。
5. ログ取得のための前記関数は更に前記定義に基づいてメモリサイズを算出する工程を備え、前記記録工程は、前記ポインタ・パラメータの指すメモリの内容量であって、前記算出されたメモリサイズに等しい量を記録することを備えることを特徴とする請求項１乃至４のいずれかに記載のログ取得方法。
6. 前記呼び出す工程の前に、ログ取得のための少なくとも１つの前記関数を選択する工程を備えることを特徴とする請求項１乃至４のいずれかに記載のログ取得方法。
7. ログの記録を停止させるための少なくとも１つの関数を選択する工程と、
   ログの記録を停止させるための少なくとも１つの関数が、ログの記録後にログの記録を停止する工程と
   を備えることを特徴とする請求項１乃至４のいずれかに記載のログ取得方法。
8. 前記ログ取得のための関数は、前記選択工程において選択された少なくとも１つの関数の実行中にエラーが発生していないか否かを判断する工程を更に備え、当該エラー判断工程においてエラーが発生したと判断された場合に、前記記録工程が開始されることを特徴とする請求項６に記載のログ取得方法。
9. 前記ログ取得のための関数は、前記選択工程において選択された少なくとも１つの関数の実行中にエラーが発生していないか否かを判断する工程を更に備え、当該エラー判断工程においてエラーが発生したと判断された場合に、前記ログ記録の停止工程により、ログの記録が停止されることを特徴とする請求項７に記載のログ取得方法。
10. ＣＯＭサーバによりエクスポートされたインターフェースと、該インターフェースに属する関数とをツリー形式で表示する工程を更に備え、前記選択工程は前記表示を介して選択を実行することを特徴とする請求項６に記載のログ取得方法。
11. ＣＯＭサーバによりエクスポートされたインターフェースと、該インターフェースに属する関数とをツリー形式で表示する工程を更に備え、前記選択工程は前記表示を介して関数を選択することを特徴とする請求項７に記載のログ取得方法。
12. 前記選択工程は、関数毎の基準で選択を実行することを特徴とする請求項１０に記載のログ取得方法。
13. 前記選択工程は、関数毎の基準で選択を実行することを特徴とする請求項１１に記載のログ取得方法。
14. 前記選択工程は、前記インターフェースを選択することにより、前記インターフェースに属する全ての関数を選択することを特徴とする請求項１０に記載のログ取得方法。
15. 前記選択工程は、前記インターフェースを選択することにより、前記インターフェースに属する全ての関数を選択することを特徴とする請求項１１に記載のログ取得方法。
16. 前記記録する工程は、日毎の基準でログを記録することを特徴とする請求項６に記載のログ取得方法。
17. ログのサイズが所定のサイズを超えた場合に、前記ログ記録工程は、新たにファイルを生成することを特徴とする請求項６に記載のログ取得方法。
18. ログの数が所定の数を超えた場合に、前記ログ記録工程は、新たにファイルを生成することを特徴とする請求項６に記載のログ取得方法。
19. メモリ内にログとして記録する前記工程は、該メモリ内のログの数が所定の数を超えた場合に、ディスク装置に該ログを移動し保存することを特徴とする請求項６に記載のログ取得方法。
20. 請求項１乃至１９のいずれかに記載のログ取得方法をコンピュータによって実行させるための制御プログラムを格納した記録媒体。
21. 請求項１乃至１９のいずれかに記載のログ取得方法をコンピュータによって実現させるための制御プログラム。

Images