(57)【要約】【課題】ソフトウェアの処理ログを容易に取得でき、かつ、バグの解析のための工数を削減することが可能なログ取得方法を提供する。【解決手段】関数（ＦｕｎｃＡＡ）を備えるプログラム９１において、実行中のログを取得するログ取得方法であって、ロードされた関数（ＦｕｎｃＡＡ）のアドレスを、ログ取得のための関数（９２）のアドレスに書き換える工程を備え、ログ取得のための関数（９２）は、関数（ＦｕｎｃＡＡ）のアドレスを呼び出し（９６）、該所定の処理を実行させ（９７）、受け取った実行結果（９８）をプログラム９１に受け渡す工程（１０１）と、プログラム９１における関数定義において、パラメータが構造体として定義されているかを判断する工程と、構造体として定義されている場合、該構造体のパッキングオプションに基づいて、該構造体の内容をメモリに配置する工程と、ログとして記録する工程とを備える。【選択図】　図４Ａ
2004038314.tif 000002
【特許請求の範囲】
【請求項１】
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記プログラムにおける関数定義において、パラメータまたは戻り値が構造体として定義されているか否かを判断する工程と、
構造体として定義されている場合、該構造体のパッキングオプションに基づいて、該構造体の内容をメモリに配置する工程と、
前記メモリに配置された構造体の内容をディスク装置にログとして記録する工程と
を備えることを特徴とするログ取得方法。
【請求項２】
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数を呼び出す際の所定の情報と、前記実行結果を受け取った際の所定の情報とをログとしてメモリに格納する工程と、
前記所定の処理を行う関数を呼び出す回数を指定する工程と、
前記指定された呼び出し回数分の所定の情報をログとして前記メモリに格納したら、該メモリに格納された所定の情報をディスク装置に移動させ、保存させる工程と
を備えることを特徴とするログ取得方法。
【請求項３】
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数を呼び出す際の所定の情報と、前記実行結果を受け取った際の所定の情報とをログとしてメモリに格納する工程と、
前記メモリに格納するサイズを指定する工程と、
前記指定されたサイズ分の所定の情報をログとして前記メモリに格納したら、該メモリに格納された所定の情報をディスク装置に移動させ、保存させる工程と
を備えることを特徴とするログ取得方法。
【請求項４】
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数を呼び出す際の所定の情報と、前記実行結果を受け取った際の所定の情報とをログとしてメモリに格納する工程と、
前記プログラムの関数定義において、パラメータまたは戻り値がメモリアドレスとして定義されているか否かを識別し、メモリアドレスとして定義されている場合には、前記プログラムの関数定義において定義された、該パラメータまたは戻り値のサイズを読み込む工程と、
前記メモリアドレス上のバイナリデータを前記読み込まれたサイズ分ログとしてして記録する工程と、
を備えることを特徴とするログ取得方法。
【請求項５】
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記プログラムの関数定義において、パラメータまたは戻り値がメモリアドレスとして定義されているか否かを識別し、メモリアドレスとして定義されている場合には、前記プログラムの関数定義において定義された、該パラメータまたは戻り値のサイズを読み込む工程と、
前記メモリアドレス上のバイナリデータを前記読み込まれたサイズ分ログとしてメモリに格納する工程と、
前記メモリに格納されたバイナリデータのうち、ディスク装置に移動させるサイズを指定する工程と、
前記読み込まれたサイズと前記指定されたサイズとを比較し、小さい方のサイズ分のバイナリデータを前記メモリからディスク装置に移動させ、保存させる工程と、
を備えることを特徴とするログ取得方法。
【請求項６】
所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記プログラムにおける関数定義において、パラメータまたは戻り値が構造体として定義されているか否かを判断する工程と、
構造体として定義されている場合、該構造体のパッキングオプションに基づいて、該構造体の内容をメモリに配置する工程と、
前記メモリに配置された構造体の内容をディスク装置にログとして記録する工程と
を備えることを特徴とするログ取得方法。
【請求項７】
所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドを呼び出す際の所定の情報と、前記実行結果を受け取った際の所定の情報とをログとしてメモリに格納する工程と、
前記所定の処理を行うメソッドを呼び出す回数を指定する工程と、
前記指定された呼び出し回数分の所定の情報をログとして前記メモリに格納したら、該メモリに格納された所定の情報をディスク装置に移動させ、保存させる工程と
を備えることを特徴とするログ取得方法。
【請求項８】
所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドを呼び出す際の所定の情報と、前記実行結果を受け取った際の所定の情報とをログとしてメモリに格納する工程と、
前記メモリに格納するサイズを指定する工程と、
前記指定されたサイズ分の所定の情報をログとして前記メモリに格納したら、該メモリに格納された所定の情報をディスク装置に移動させ、保存させる工程と
を備えることを特徴とするログ取得方法。
【請求項９】
所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドを呼び出す際の所定の情報と、前記実行結果を受け取った際の所定の情報とをログとしてメモリに格納する工程と、
前記プログラムの関数定義において、パラメータまたは戻り値がメモリアドレスとして定義されているか否かを識別し、メモリアドレスとして定義されている場合には、前記プログラムの関数定義において定義された、該パラメータまたは戻り値のサイズを読み込む工程と、
前記メモリアドレス上のバイナリデータを前記読み込まれたサイズ分ログとしてして記録する工程と、
を備えることを特徴とするログ取得方法。
【請求項１０】
所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記プログラムの関数定義において、パラメータまたは戻り値がメモリアドレスとして定義されているか否かを識別し、メモリアドレスとして定義されている場合には、前記プログラムの関数定義において定義された、該パラメータまたは戻り値のサイズを読み込む工程と、
前記メモリアドレス上のバイナリデータを前記読み込まれたサイズ分ログとしてメモリに格納する工程と、
前記メモリに格納されたバイナリデータのうち、ディスク装置に移動させるサイズを指定する工程と、
前記読み込まれたサイズと前記指定されたサイズとを比較し、小さい方のサイズ分のバイナリデータを前記メモリからディスク装置に移動させ、保存させる工程と、
を備えることを特徴とするログ取得方法。
【請求項１１】
請求項１乃至１０のいずれか１つに記載のログ取得方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
【請求項１２】
請求項１乃至１０のいずれか１つに記載のログ取得方法をコンピュータによって実現させるための制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数にモジュール分けされたソフトウェアの処理ログを取得するための技術に関するものである。
【０００２】
【従来の技術】
従来より、再現率の低いソフトウェアの障害に対しては、ソフトウェアの処理ログを取得し、当該処理ログを解析することによって、障害の原因をつきとめ、その対策を講じてきた。
【０００３】
【発明が解決しようとする課題】
しかし、上記従来の処理ログの取得には以下のような問題点がある。
（１）ユーザの動作環境でもログを取得しつづけるためには、ソフトウェアのモジュール自体に手を加え、処理ログ取得ルーチンを追加しなければならず、処理ログ取得のための作業負荷が大きかった。
（２）処理ログ取得はモジュール毎に行うため、生成されたログはモジュール単位のものとなってしまい、ソフトウェア全体の処理を、完全に時間順のログとして取得するのが困難である。このため、全体の処理ログとしての見通しが悪く、ログを解析して障害の原因を発見するまでのプロセスに工数がかかっていた。
【０００４】
本発明は、上記課題を鑑みてなされたものであり、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能なログ取得方法、ならびに該方法をコンピュータによって実現させるためのプログラム、および該プログラムを格納した記憶媒体を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記の目的を達成するために本発明に係るログ取得方法は以下のような構成を備える。即ち、
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記プログラムにおける関数定義において、パラメータまたは戻り値が構造体として定義されているか否かを判断する工程と、
構造体として定義されている場合、該構造体のパッキングオプションに基づいて、該構造体の内容をメモリに配置する工程と、
前記メモリに配置された構造体の内容をディスク装置にログとして記録する工程とを備える。
【０００６】
【発明の実施の形態】
【第１の実施形態】
本実施形態は、あるモジュールから別のモジュール内に存在する関数の呼び出しが行われる際の仕組みである、メモリに保持されたインポート関数アドレス、または仮想関数アドレステーブル（Ｖｉｒｔｕａｌ　Ａｄｄｒｅｓｓ　Ｔａｂｌｅ）を利用して、モジュール間の関数呼び出しをフックしてログに記録することで、ソフトウェアのモジュール自体に手を加えることなく、ソフトウエア全体の処理を、時間順のログとして取得することを可能にするものである。以下に具体的に説明する。
【０００７】
＜システム構成＞
図１は、本発明の各実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。説明を簡略化するために、本実施形態では、本ソフトウェア評価システムが１台のＰＣ内部に構築されるものとするが、本発明のログ取得方法の特徴は１台のＰＣ内部に構築されるか、あるいは複数のＰＣにネットワークシステムとして構築されるかによらず有効である。
【０００８】
本ソフトウェア評価システムを搭載するコンピュータには、ＣＰＵ１、チップセット２、ＲＡＭ３、ハードディスクコントローラ４、ディスプレイコントローラ５、ハードディスクドライブ６、ＣＤ−ＲＯＭドライブ７、ディスプレイ８が搭載されている。また、ＣＰＵとチップセットを繋ぐ信号線１１、チップセット２とＲＡＭ３とを繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とハードディスクドライブ６とを繋ぐ信号線１４、ハードディスクコントローラ４とＣＤ−ＲＯＭドライブ７とを繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８とを繋ぐ信号線１６が搭載されている。
【０００９】
＜関数処理に対する処理ログ取得＞
本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムを説明するために、まず図２によって、複数のモジュールに分かれたソフトウェアが、通常の状態でどのようにメモリにロードされるかを説明する。
【００１０】
通常、複数のモジュールに分かれたソフトウェアは、全体の制御を行う実行ファイルＥＸＥ（２３）と、モジュールとして存在しＥＸＥの補完的な役割を担うダイナミックリンクライブラリＤＬＬ（２７）とに分かれており、メモリにはＥＸＥとＤＬＬの両方がロードされる。ＥＸＥはコードセグメント（２８）とデータセグメント（２９）、そしてインポート関数アドレステーブル（２２）から成っている。更に、インポート関数アドレステーブルは、関数の所属するＤＬＬによって分かれており（２１，　２４）、ＤＬＬごとにそれぞれの関数がロードされたアドレスが書かれている（３０〜３５）。ＤＬＬの関数の実体は、ＤＬＬごとに分かれて（２５，　２６）ロードされ、それぞれの関数は該当するＤＬＬの一部としてロードされる（３６〜４１）。この図では、１本のＥＸＥがＡ．ＤＬＬ及びＢ．ＤＬＬの２つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はＦｕｎｃ　ＡＡ，　Ｆｕｎｃ　ＡＢ，　Ｆｕｎｃ　ＡＣ，　Ｆｕｎｃ　ＢＡ，　Ｆｕｎｃ　ＢＢ，　Ｆｕｎｃ　ＢＣの６個となっている。
【００１１】
ＥＸＥのコードセグメント内にあるコードが関数Ｆｕｎｃ　ＡＡを呼び出す場合には、まずインポート関数アドレステーブル内に書かれたＦｕｎｃ　ＡＡのアドレス（３０）が読み込まれる。ここには実際にはＡ．ＤＬＬの一部として読み込まれたＦｕｎｃ　ＡＡコード（３６）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＡ．ＤＬＬのＦｕｎｃ　ＡＡを呼び出すことができる。
【００１２】
図３は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してＩＡＴ　Ｐａｔｃｈ（Ｉｍｐｏｒｔ　Ａｄｄｒｅｓｓ　Ｔａｂｌｅ　Ｐａｔｃｈ）という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている。
【００１３】
ログ取得が開始されると、メモリ内にはＩＡＴ　Ｐａｔｃｈ用のＤＬＬであるＣ．ＤＬＬ（５８）がロードされる。Ｃ．ＤＬＬはインポート関数アドレステーブル（５２）内に書かれた関数のアドレスを、Ｃ．ＤＬＬ内のログ取得コードであるＦｕｎｃ　ＣＡＡ，　Ｆｕｎｃ　ＣＡＢ，　Ｆｕｎｃ　ＣＡＣ，　Ｆｕｎｃ　ＣＢＡ，Ｆｕｎｃ　ＣＢＢ，　Ｆｕｎｃ　ＣＢＣのアドレスに書き換える（６１〜６６）。Ｃ．ＤＬＬ内のＦｕｎｃ　ＣＡＡ，　Ｆｕｎｃ　ＣＡＢ，　Ｆｕｎｃ　ＣＡＣ，　Ｆｕｎｃ　ＣＢＡ，　Ｆｕｎｃ　ＣＢＢ，　Ｆｕｎｃ　ＣＢＣのコード（７３〜７８）は、ログを記録すると共に、元々の関数呼び出しを受けるべくメモリにロードされている、該当する関数であるＦｕｎｃ　ＡＡ，　Ｆｕｎｃ　ＡＢ，　Ｆｕｎｃ　ＡＣ，　Ｆｕｎｃ　ＢＡ，　Ｆｕｎｃ　ＢＢ，　Ｆｕｎｃ　ＢＣ（６７〜７２）を呼び出す。
【００１４】
図４Ａは、図３におけるＩＡＴ　Ｐａｔｃｈの処理をあらわす図、図４Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＡ．ＤＬＬ内のＦｕｎｃ　ＡＡを呼び出す際に、ＩＡＴ　Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００１５】
ＥＸＥ（図４Ａの９１）がＦｕｎｃ　ＡＡをコールすると（図４Ａの９４）、Ｃ．ＤＬＬ内にあるログ取得コードがＤＬＬ名／関数名をメモリに保存し（図４ＢのステップＳ４０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図４Ａの９５、図４ＢのステップＳ４０３）。その後Ｃ．ＤＬＬは本来呼び出されるはずであった、Ａ．ＤＬＬ（図４Ａの９３）内のＦｕｎｃ　ＡＡをコールする（図４Ａの９６、図４ＢのステップＳ４０４）。Ａ．ＤＬＬのＦｕｎｃ　ＡＡ処理（図４Ａの９７）が終了し、Ｃ．ＤＬＬに制御がリターンすると（図４Ａの９８）、Ｃ．ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図４Ａの９９）。その後、Ｃ．ＤＬＬは保存したログ情報をファイルに書き込み（図４Ａの１００、図４ＢのステップＳ４０５）、あたかもＡ．ＤＬＬのＦｕｎｃ　ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（１０１）。
【００１６】
図５は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のＥＸＥ（１１３）が、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）内の関数を呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１１４）、処理ログを生成している（１１５）。ＡＰＩトレーサは、ＤＬＬ−１やＤＬＬ−２の関数定義を記述したファイル（１１１）と、どのＤＬＬのどの関数のインポート関数テーブルを書き換えてログを取得するかの設定シナリオ（トレースシナリオ１１２）を元に動作する。
【００１７】
＜メソッド処理に対する処理ログ取得＞
次に、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、実行ファイルＥＸＥ（１１８）がＣＯＭ（Ｃｏｍｐｏｎｅｎｔ　Ｏｂｊｅｃｔ　Ｍｏｄｅｌ）サーバでエクスポートされているインターフェースのインスタンス作成時に、どのようにメモリにロードされるかを説明するために、まず、図６によって、通常の状態でどのようにメモリにロードされるかを説明する。
【００１８】
通常、インターフェースのインスタンス作成を行うと、ＣＯＭサーバ内で、要求されたインターフェース（１２１，　１２２）と、そのメソッド（：オブジェクト指向プログラミングにおいて、オブジェクトの実行する手続きを記述したプログラム、１３０〜１３５）が作成され、それらは、メモリ上に両方がロードされる。ここで、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ（仮想アドレステーブル）は作成された各インターフェース毎に作られ（１１８，　１２０）、作成要求を行ったＥＸＥに渡される。このｖｉｒｔｕａｌ　ａｄｄｒｅｓ　ｔａｂｌｅには各メソッドの作成されたアドレスが書かれている（１２４〜１２９）。ＥＸＥはこれら情報を利用し、各インターフェースに対して呼び出しを行う。この図では、１本のＥＸＥがＩｎｔｅｒｆａｃｅ　Ａ及びＩｎｔｅｒｆａｃｅ　Ｂの２つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Ｍｅｔｈｏｄ　ＡＡ，　Ｍｅｔｈｏｄ　ＡＢ，　Ｍｅｔｈｏｄ　ＡＣ，　Ｍｅｔｈｏｄ　ＢＡ，　Ｍｅｔｈｏｄ　ＢＢ，　Ｍｅｔｈｏｄ　ＢＣとなっている。
【００１９】
ＥＸＥのコードが関数Ｍｅｔｈｏｄ　ＡＡを呼び出す場合には、まずｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ内に書かれたＭｅｔｈｏｄ　ＡＡのアドレス（１２４）が読み込まれる。ここには実際にはＣＯＭサーバのＩｎｔｅｒｆａｃｅ　Ａの一部として作成されたＭｅｔｈｏｄ　ＡＡコード（１３０）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＩｎｔｅｒｆａｃｅ　ＡのＭｅｔｈｏｄ　ＡＡを呼び出すことができる。
【００２０】
図７は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図６とは、ログ取得用のコードに対してＶＴａｂｌｅ　Ｐａｔｃｈ（ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ　Ｐａｔｃｈ）という手法を用いて、メソッド呼び出しをリダイレクトしているという点で異なっている。
【００２１】
ログ取得が開始されると、メモリ内にはＶＴａｂｌｅ　Ｐａｔｃｈ用のＤＬＬ（１４３）がロードされる。このＤＬＬはｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ（１３６，　１３８）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ　Ａ’Ａ，　Ｍｅｔｈｏｄ　Ａ’Ｂ，　ＭｅｔｈｏｄＡ’Ｃ，　Ｍｅｔｈｏｄ　Ｂ’Ａ，　Ｍｅｔｈｏｄ　Ｂ’Ｂ，　Ｍｅｔｈｏｄ　Ｂ’Ｃのアドレスに書き換える（１４５〜１５０）。ＤＬＬ内のＭｅｔｈｏｄ　Ａ’Ａ，Ｍｅｔｈｏｄ　Ａ’Ｂ，　Ｍｅｔｈｏｄ　Ａ’Ｃ，　Ｍｅｔｈｏｄ　Ｂ’Ａ，　Ｍｅｔｈｏｄ　Ｂ’Ｂ，　Ｍｅｔｈｏｄ　Ｂ’Ｃのコード（１５７〜１６２）は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるＭｅｔｈｏｄ　ＡＡ，　Ｍｅｔｈｏｄ　ＡＢ，　Ｍｅｔｈｏｄ　ＡＣ，　Ｍｅｔｈｏｄ　ＢＡ，　Ｍｅｔｈｏｄ　ＢＢ，　Ｍｅｔｈｏｄ
ＢＣ（１５７〜１６２）を呼び出す。
【００２２】
図８Ａは、図７におけるＶＴａｂｌｅ　Ｐａｔｃｈの処理をあらわす図、図８Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＣＯＭサーバ内のＩｎｔｅｒｆａｃｅ　ＡのＭｅｔｈｏｄＡＡを呼び出す際に、ＶＴａｂｌｅ　Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００２３】
ＥＸＥ（図８Ａの１６３）がＭｅｔｈｏｄ　ＡＡをコールすると（図８Ａの１６６）、ＤＬＬ内にあるログ取得コードがモジュール名／インターフェース名／メソッド名をメモリに保存し（図８ＢのステップＳ８０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図８Ａの１６７、図８ＢのステップＳ８０３））。その後ＤＬＬは本来呼び出されるはずであった、ＣＯＭサーバ（図８Ａの１６５）内のＭｅｔｈｏｄ　ＡＡをコールする（図８Ａの１６８、図８ＢのステップＳ８０４））。ＣＯＭサーバのＭｅｔｈｏｄ　ＡＡ処理（図８Ａの１６９）が終了し、ＤＬＬに制御がリターンすると（図８Ａの１７０）、ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図８Ａの１７１）。その後、ＤＬＬは保存したログ情報をファイルに書き込み（図８Ａの１７２、図８ＢのステップＳ８０５）、あたかもＣＯＭサーバのＭｅｔｈｏｄ　ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（図８Ａの１７３）。
【００２４】
図９は、本発明の第１の実施形態にかかるソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のＥＸＥ（１７６）が、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２（１８０）内のメソッドを呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１７７）、処理ログを生成している（１７８）。ＡＰＩトレーサは、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２の関数定義を記述したファイル（１７４）と、どのＣＯＭサーバのどのインターフェースのどのメソッドのｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅを書き換えてログを取得するかの設定シナリオ（トレースシナリオ１７５）を元に動作する。
【００２５】
＜関数定義ファイル＞
図１０は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【００２６】
同図において示された、パッキングオプション（ＰａｃｋｉｎｇＯｐｔｉｏｎ）のバイト数が、本発明の特徴となる定義部分である。
【００２７】
図１１は、図１０に示した関数定義ファイルを用いて、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻、及びその際のパラメータ／戻り値が、ログとして生成される。
【００２８】
図１２の説明に入る前に、従来広く用いられている、構造体のパッキングオプションに関して説明する。
【００２９】
構造体のパッキングオプションとは、構造体の実体をメモリに配置する際に、どのようなアライメントでメモリに配置するかに関しての取り決めであり、モジュール間で構造体を受け渡しする際に用いられるものである。
【００３０】
通常のＣＰＵでは、構造体のメンバはＣＰＵの速度を落とさずに内容をレジスタに読み込むことができるようなメモリ配置に置かれている。例えば、データバス幅が６４ｂｉｔのＣＰＵでは、以下のようなメモリ境界にメンバを配置することで、ＣＰＵの速度を落とさずにメモリ内容をレジスタに読み込むことができる。
１　ｂｙｔｅ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００１，　０ｘ０００００００２，，，
２　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００２，　０ｘ０００００００４，，，（ｌｅａｓｔ　１　ｂｉｔ　ｉｓ　ｚｅｒｏ）
４　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００４，　０ｘ０００００００８，，，（ｌｅａｓｔ　２　ｂｉｔｓ　ａｒｅ　ｚｅｒｏ）
８　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００８，　０ｘ００００００１０，，，（ｌｅａｓｔ　３　ｂｉｔｓ　ａｒｅ　ｚｅｒｏ）
これは、通常のＣＰＵがメモリアドレスを計算する際に、データサイズで割り切れるメモリアドレスからデータを読み込む方が、そうでないメモリアドレスからデータを読み込むよりも速いという特性に依存している。
【００３１】
ただし、このようにデータを配置すると、メモリ内に使用されていない空間が大量に残ることになるため、速度に関しては最適化することができても、使用メモリ量に対しては悪影響を及ぼす。
【００３２】
その悪影響を回避するために、通常コンパイラには、構造体パッキングオプションというオプションが用意されている。例えば、８バイトのデータ計算は遅くても構わないため使用メモリ量の低減を優先したいが、４バイト以下のデータに関してはメモリ量よりも速度を優先したいという場合、構造体のパッキングオプションを４としてプログラム（この実施形態においてはＥＸＥとＤＬＬの両方）をコンパイルすることで、次のようなメモリ境界に構造体の各メンバを配置することができる。
１　ｂｙｔｅ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００１，　０ｘ０００００００２，，，
２　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００２，　０ｘ０００００００４，，，（ｌｅａｓｔ　１　ｂｉｔ　ｉｓ　ｚｅｒｏ）
４　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００４，　０ｘ０００００００８，，，（ｌｅａｓｔ　２　ｂｉｔｓ　ａｒｅ　ｚｅｒｏ）
８　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００４，　０ｘ０００００００８，，，（ｌｅａｓｔ　２　ｂｉｔｓ　ａｒｅ　ｚｅｒｏ）
この場合は、４バイト以下のデータのみ、データサイズで割り切れるメモリアドレスに配置される。
【００３３】
１バイト以下のデータのみ、データサイズで割り切れるメモリアドレスに配置したい場合は、構造体のパッキングオプションを１としてプログラムをコンパイルすることで、次のようなメモリ境界に構造体の各メンバを配置することができる。
１　ｂｙｔｅ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００１，　０ｘ０００００００２，，，
２　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００２，　０ｘ０００００００４，，，（ｌｅａｓｔ　１　ｂｉｔ　ｉｓ　ｚｅｒｏ）
４　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００２，　０ｘ０００００００４，，，（ｌｅａｓｔ　１　ｂｉｔ　ｉｓ　ｚｅｒｏ）
８　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００２，　０ｘ０００００００４，，，（ｌｅａｓｔ　１　ｂｉｔ　ｉｓ　ｚｅｒｏ）
２バイト以下のデータのみ、データサイズで割り切れるメモリアドレスに配置したい場合は、構造体のパッキングオプションを２としてプログラムをコンパイルすることで、次のようなメモリ境界に構造体の各メンバを配置することができる。
１　ｂｙｔｅ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００１，　０ｘ０００００００２，，，
２　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００１，　０ｘ０００００００２，，，
４　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００１，　０ｘ０００００００２，，，
８　ｂｙｔｅｓ　ｄａｔａ　−＞０ｘ００００００００，　０ｘ０００００００１，　０ｘ０００００００２，，，
図１２は、以上に説明した構造体のパッキングオプションに関するより具体的な例である。構造体のメンバが１バイトのデータと８バイトのデータの２つである場合、構造体のパッキングオプションに応じて、ＥＸＥとＤＬＬの間でパラメータ乃至戻り値として受け渡しされる構造体が、この図のようにメモリに配置される。
【００３４】
図１３は、構造体のパッキングオプションに関する別の例である。構造体のメンバが１バイトのデータと４バイトのデータの２つである場合、構造体のパッキングオプションに応じて、ＥＸＥとＤＬＬの間でパラメータ乃至戻り値として受け渡しされる構造体が、この図のようにメモリに配置される。
【００３５】
図１４は、構造体のパッキングオプションに関する別の例である。構造体のメンバが１バイトのデータと２バイトのデータの２つである場合、構造体のパッキングオプションに応じて、ＥＸＥとＤＬＬの間でパラメータ乃至戻り値として受け渡しされる構造体が、この図のようにメモリに配置される。
【００３６】
これらの例はあくまでも構造体のパッキングオプションを説明するための例であり、本発明の効果は構造体パッキングオプションの種類を問わず有効である。本発明は、トレースする関数／メソッドのパラメータ乃至戻り値に構造体が入っている場合に、予め関数定義ファイルで指定された構造体パッキングオプションに応じて、自動的に構造体の内容を展開するところに特徴がある。
【００３７】
図１５は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【００３８】
設定された関数／メソッドが呼び出されることによって、処理が開始されると（ステップＳ１）、関数定義ファイルから構造体のパッキングオプションを読み込み（ステップＳ２）、ＤＬＬ名／関数名／呼び出し時の時刻をＨＤＤに保存する（ステップＳ３）。
【００３９】
次に、パラメータが構造体として定義されているかどうかを、図１０に示した関数定義ファイルに基づいて判断し（ステップＳ４）、構造体として定義されていない場合は、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ５）。構造体として定義されている場合は、ステップＳ２において読み込まれた構造体のパッキングオプションに基づいて構造体の内容をメモリから展開し（ステップＳ６）、それぞれのメンバをＨＤＤに保存する（ステップＳ７）。
【００４０】
関数内部の処理が終了すると（ステップＳ８）、ＤＬＬ名／関数名／終了時の時刻をＨＤＤに保存する（ステップＳ９）。次に、パラメータ及び戻り値が構造体として定義されているかどうかを、図１０に示した関数定義ファイルに基づいて判断し（ステップＳ１０）、構造体として定義されていない場合は、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ１１）。構造体として定義されている場合は、ステップＳ２において読み込まれた構造体のパッキングオプションに基づいて構造体の内容をメモリから展開し（ステップＳ１２）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ１３）。
【００４１】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ１４）続行される。
【００４２】
以上の説明から明らかなように、本実施形態にかかるログ取得方法によれば、複数にモジュール分けされたソフトウエアの処理ログの取得において、モジュール自体に変更を加えることなく、モジュール内に用意された関数／メソッドの呼び出しをログとして記録することが可能となり、処理ログ取得のための作業負荷を低減することが可能となる。また、生成されるログは、時間順のログとして取得することができ、ログの解析が容易となるため、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。さらに、関数定義において、パッキングオプションを用いることで、ログ取得時の使用メモリ量を低減することが可能となる。
【００４３】
【第２の実施形態】
上記第１の実施形態では、パッキングオプションを用いることで、ログ取得時の使用メモリ量を低減する場合について述べたが、メモリにバッファリングするログデータの数を制限することで、ログ取得時の使用メモリ量を一定値以下に制限することも可能である。
【００４４】
図１６は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例である。ＤＬＬ名及び関数／メソッド名を記述し、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本実施形態にかかるログ取得方法を実現するソフトウェア評価システムは、この関数定義ファイルによって指示された内容をもとに、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。
【００４５】
図１７は、図１６に示した関数定義ファイルを用いて、本実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻、及びその際のパラメータ／戻り値が、ログとして生成される。
【００４６】
図１８は、図１７に示したログをメモリ保存する際の、メモリ構成をあらわす図である。それぞれの関数呼び出しに対して、あるメモリオフセットに対してデータ及びＩｎｄｅｘが保存される。
【００４７】
図１９は、本実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【００４８】
設定された関数／メソッドが呼び出されることによって、処理が開始されると（ステップＳ２１）、Ｉｎｄｅｘのカウント用に指定されたレジスタ乃至メモリエリアをゼロにクリアし（ステップＳ２２）、メモリにバッファリングするＩｎｄｅｘ数の設定を読み込む（ステップＳ２３）。次に、Ｉｎｄｅｘを図１８で示されたＩｎｄｅｘエリアに保存し（ステップＳ２４）、ＤＬＬ名／関数名／呼び出し時の時刻をメモリに保存し（ステップＳ２５）、その呼び出しに対してのパラメータをメモリに保存して（ステップＳ２６）、関数／メソッドを呼び出す（ステップＳ２７）。
【００４９】
関数内部の処理が終了すると、ＤＬＬ名／関数名／終了時の時刻をメモリに保存し（ステップＳ２８）、その呼び出しに対してのパラメータ及び戻り値をメモリに保存する（ステップＳ２９）。次に、ステップＳ２３によって読み込まれた設定と現在のＩｎｄｅｘとを比較し（ステップＳ３０）、Ｉｎｄｅｘよりも設定の方が大きいか、あるいは同じである場合には、ログデータをＨＤＤに移動せずに、単にＩｎｄｅｘをインクリメントして（ステップＳ３１）、ステップＳ２４の処理に戻る。設定よりもＩｎｄｅｘの方が大きい場合、メモリに保持されたデータをＨＤＤに移動し、メモリの内容をゼロクリアする（ステップＳ３２）。
【００５０】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ３３）続行される。
【００５１】
【第３の実施形態】
上記第２の実施形態においては、ログ取得時の使用メモリ量を一定値以下に制限すべく、Ｉｎｄｅｘ数をカウントすることとしたが、ログデータのサイズにより制限することも可能である。
【００５２】
図２０は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、別な一例をあらわす処理の流れを示す図である。
【００５３】
設定された関数／メソッドが呼び出されることによって、処理が開始されると（ステップＳ４１）、Ｉｎｄｅｘのカウント用に指定されたレジスタ乃至メモリエリアをゼロにクリアし（ステップＳ４２）、メモリにバッファリングするログサイズの設定を読み込む（ステップＳ４３）。次に、Ｉｎｄｅｘを図１８で示されたＩｎｄｅｘエリアに保存し（ステップＳ４４）、ＤＬＬ名／関数名／呼び出し時の時刻をメモリに保存し（ステップＳ４５）、その呼び出しに対してのパラメータをメモリに保存して（ステップＳ４６）、関数／メソッドを呼び出す（ステップＳ４７）。関数内部の処理が終了すると、ＤＬＬ名／関数名／終了時の時刻をメモリに保存し（ステップＳ４８）、その呼び出しに対してのパラメータ及び戻り値をメモリに保存する（ステップＳ４９）。
【００５４】
次に、ステップＳ４３によって読み込まれた設定と、現在のＩｎｄｅｘまでにメモリに保存されたデータのサイズを比較し（ステップＳ５０）、メモリに保存されたデータのサイズよりも設定されたサイズの方が大きいか、あるいは同じである場合には、ログデータをＨＤＤに移動せずに、単にＩｎｄｅｘをインクリメントして（ステップＳ５１）、ステップＳ４４の処理に戻る。設定されたサイズよりも、メモリに保存されたデータのサイズの方が大きい場合、メモリに保持されたデータを一つ前のＩｎｄｅｘまでの分だけＨＤＤに移動し、一つ前のＩｎｄｅｘまでの分のメモリの内容をゼロクリアする（ステップＳ５２）。一つ前までのデータをメモリからＨＤＤに移動することで、メモリ使用量が指定サイズを超えない状態を保持することができる。
【００５５】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ５３）続行される。
【００５６】
【第４の実施形態】
図２１は、上記第２および第３の実施形態で示された機能を設定するための、ユーザーインターフェイスの例を示す図である。ログのメモリバッファリングを行う設定として、レコード数による指定すなわち第２の実施形態のＩｎｄｅｘによる指定と、ログデータのサイズによる指定すなわち第３の実施形態の指定が可能である。
【００５７】
【第５の実施形態】
上記各実施形態においては、ログ取得時の使用メモリ量を低減する場合について述べたが、ＨＤＤに保存するログファイルのデータ量を低減させることもできる。
【００５８】
図２２は、本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。ＤＬＬ名及び関数／メソッド名を記述し、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本実施形態にかかるログ取得方法を実現するソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。
【００５９】
図２２において示された、Ａ．ＤＬＬ内の関数ＦｕｎｃＡＢに対する関数定義は、本実施形態を最もよくあらわすものである。引数には、データの格納先として示されるポインタｐＢｕｆと、そのデータのサイズとして示されるｄｗＢｕｆＳｉｚｅが定義されており、ｐＢｕｆとｄｗＢｕｆＳｉｚｅとの相関、すなわちｐＢｕｆに格納されたデータのサイズがｄｗＢｕｆＳｉｚｅによって指示されているという相関が定義されている。
【００６０】
図２３は、図２２に示した関数定義ファイルを用いて、本実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻、及びその際のパラメータ／戻り値が、ログとして生成される。
【００６１】
図２３において示された、Ａ．ＤＬＬ内の関数ＦｕｎｃＡＢに対する呼び出しのログは、図２２の関数定義ファイルと共に、本実施形態の特徴を最もよく表すものである。図２２に示した関数定義に基づいて、ＦｕｎｃＡＢに対する呼び出しの際には、引数としてのｐＢｕｆの値だけでなく、その値が指し示すアドレス上にある、ｄｗＢｕｆＳｉｚｅ分すなわち２４ｂｙｔｅ分のデータが、通常のログとは別のバイナリログとして保存され、そのバイナリログファイル内に保存された、該当するＦｕｎｃＡＢの呼び出しのＩＤ、すなわちＤａｔａＩＤが、追加情報としてログに保存される。
【００６２】
図２４は、図２３に示したログと共に保存された、バイナリログファイルの内容をあらわす例である。タグとしてＤａｔａＩＤが保存され、そのＤａｔａＩＤ毎にバイナリデータが保存されている。
【００６３】
図２２〜図２４に示された関数定義ファイル、ログ、バイナリログに示された実施形態は、指示するデータが入力データか出力データか、あるいは戻り値かに依存せずに有効である。例えば、関数からの出力パラメータとしてデータアドレスが戻され、更に関数からの戻り値としてデータサイズが出力された場合にも、同様にデータ本体のログを取得することが可能である。
【００６４】
図２５は、本実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【００６５】
設定された関数／メソッドが呼び出されることによって、処理が開始されると（ステップＳ６１）、ＤＬＬ名／関数名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ６２）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ６３）。
【００６６】
次に、パラメータがメモリアドレスとして定義されているかどうかを、図２２に示した関数定義ファイルに基づいて判断し（ステップＳ６４）、定義されている場合は、サイズをあらわす引数からデータサイズを取得し（ステップＳ６５）、そのサイズ分のデータをメモリから読み込んで（ステップＳ６６）、ＤａｔａＩＤをつけてデータをＨＤＤのバイナリログファイルに保存する（ステップＳ６７）。パラメータがメモリアドレスとして定義されていない場合、ステップＳ６５からステップＳ６７の処理は行われない。
【００６７】
関数内部の処理が終了すると（ステップＳ６８）、ＤＬＬ名／関数名／終了時の時刻をＨＤＤに保存し（ステップＳ６９）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ７０）。
【００６８】
次に、パラメータがメモリアドレスとして定義されているかどうかを、図２２に示した関数定義ファイルに基づいて判断し（ステップＳ７１）、定義されている場合は、サイズをあらわす引数からデータサイズを取得し（ステップＳ７２）、そのサイズ分のデータをメモリから読み込んで（ステップＳ７３）、ＤａｔａＩＤをつけてデータをＨＤＤのバイナリログファイルに保存する（ステップＳ７４）。パラメータがメモリアドレスとして定義されていない場合、ステップＳ７２からＳ７４の処理は行われない。
【００６９】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ７５）続行される。
【００７０】
以上の説明から明らかなように、関数定義ファイルにおいてパラメータがメモリアドレスとして定義され、かつ当該メモリアドレスに該当するバイナリデータをログファイルとして保存する場合において、関数定義ファイルにおいて定義されたサイズ分のバイナリデータのみをログファイルとして保存することにより、ＨＤＤに保存するログファイルのデータ量を削減することが可能となる。
【００７１】
【第６の実施形態】
上記第５の実施形態では、バイナリパラメータ（パラメータがメモリアドレスとして定義され、そのメモリアドレス上に格納されたバイナリデータ）の保存にあたり、サイズ引数より取得したデータサイズ分のデータを保存することとしたが、指定サイズ以上のデータは保存しないようにすることも可能である。
【００７２】
図２６及び図２７は、本発明の第６の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、別な一例の処理の流れを示す図である。
【００７３】
設定された関数／メソッドが呼び出されることによって、処理が開始されると（ステップＳ８１）、ＤＬＬ名／関数名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ８２）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ８３）。
【００７４】
次に、パラメータがメモリアドレスとして定義されているかどうかを、図２２に示した関数定義ファイルに基づいて判断し（ステップＳ８４）、定義されている場合は、サイズをあらわす引数からデータサイズを取得する（ステップＳ８５）。次に、バイナリデータ取得の上限設定があるかどうかを判断し（ステップＳ８６）、上限設定が行われていない場合は、サイズをあらわす引数に示された全体サイズ分のデータをメモリから読み込んで（ステップＳ８７）、ＤａｔａＩＤをつけてデータをＨＤＤのバイナリログファイルに保存する（ステップＳ８８）。上限設定が行われている場合は、設定された上限サイズ分のデータをメモリから読み込んで（ステップＳ８９）、ＤａｔａＩＤをつけてデータをＨＤＤのバイナリログファイルに保存する（ステップＳ９０）。パラメータがメモリアドレスとして定義されていない場合、ステップＳ８５からＳ９０の処理は行われない。
【００７５】
関数内部の処理が終了すると（ステップＳ９１）、ＤＬＬ名／関数名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ９２）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ９３）。
【００７６】
次に、パラメータがメモリアドレスとして定義されているかどうかを、図２２に示した関数定義ファイルに基づいて判断し（ステップＳ９４）、定義されている場合は、サイズをあらわす引数からデータサイズを取得する（ステップＳ９５）。次に、バイナリデータ取得の上限設定があるかどうかを判断し（ステップＳ９６）、上限設定が行われていない場合は、サイズをあらわす引数に示された全体サイズ分のデータをメモリから読み込んで（ステップＳ９７）、ＤａｔａＩＤをつけてデータをＨＤＤのバイナリログファイルに保存する（ステップＳ９８）。上限設定が行われている場合は、設定された上限サイズ分のデータをメモリから読み込んで（ステップＳ９９）、ＤａｔａＩＤをつけてデータをＨＤＤのバイナリログファイルに保存する（ステップＳ１００）。パラメータがメモリアドレスとして定義されていない場合、ステップＳ９５からＳ１００の処理は行われない。
【００７７】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ１０１）続行される。
【００７８】
【第７の実施形態】
図２８は、第５のおよび第６の実施形態で示された機能を設定するための、ユーザーインターフェイスの例を示す図である。ログに保存する対象として、入力パラメータ、出力パラメータと共に、バイナリパラメータを保存するかどうかの設定が存在し、バイナリパラメータを保存するという設定が行われた場合、第５の実施形態に示した処理が行われる。また、バイナリパラメータを保存するという設定が行なわれ、尚且つ指定サイズ以上のデータは保存しないという設定が行なわれていて、サイズが指定されている場合、第６の実施形態に示した処理が行われる。
【００７９】
【第８の実施形態】
図２９は、図２２に示された基本ログ内に記述されたＤａｔａＩＤと、図２３に示されたバイナリログの該ＤａｔａＩＤにおけるデータとを関連させるユーザーインターフェイスを示す図である。かかるユーザーインターフェースにより、ＤａｔａＩＤにおけるデータを容易に参照することが可能となる。通常ログ表示において、そのパラメータがメモリアドレスをあらわすパラメータであることが明示され、その部分をユーザがマウスクリックなどによって選択することによって、該ＤａｔａＩＤに対応するデータが表示される。
【００８０】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００８１】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００８２】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００８３】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００８４】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８５】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８６】
【発明の効果】
以上説明したように本発明によれば、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。
【図２】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、関数ロード時の通常のメモリ構成をあらわす図である。
【図３】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ　Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図４Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ　Ｐａｔｃｈを使用時の状態を示す図である。
【図４Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図５】本発明の第１の実施形態にかかるソフトウェア評価システムのＩＡＴ　Ｐａｔｃｈを使用時の内部構成をあらわす図である。
【図６】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、ＣＯＭサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。
【図７】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ　Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図８Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ　Ｐａｔｃｈを使用時の状態を示す図である。
【図８Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図９】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、内部構成をあらわす図である。
【図１０】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図１１】図１０に示した関数定義ファイルを用いて、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図１２】構造体のパッキングオプションに関する具体的な例を示す図である。
【図１３】構造体のパッキングオプションに関する別の例を示す図である。
【図１４】構造体のパッキングオプションに関する別の例を示す図である。
【図１５】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【図１６】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図１７】図１６に示した関数定義ファイルを用いて、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図１８】図１７に示したログをメモリ保存する際の、メモリ構成をあらわす図である。
【図１９】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【図２０】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、別な一例をあらわす処理の流れを示す図である。
【図２１】本発明の第２および第３の実施形態で示された機能を設定するための、ユーザーインターフェイスの例を示す図である。
【図２２】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図２３】図２２に示した関数定義ファイルを用いて、本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図２４】図２３に示したログと共に保存された、バイナリログファイルの内容をあらわす図である。
【図２５】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【図２６】本発明の第６の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、別な一例の処理の流れを示す図である。
【図２７】本発明の第６の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、別な一例の処理の流れを示す図である。
【図２８】本発明の第５のおよび第６の実施形態で示された機能を設定するための、ユーザーインターフェイスの例を示す図である。
【図２９】図２２に示された基本ログ内に記述されたＤａｔａＩＤと、図２３に示されたバイナリログの該ＤａｔａＩＤにおけるデータとを関連させるユーザーインターフェイスを示す図である。
【符号の説明】
１：ＣＰＵ
２：チップセット
３：ＲＡＭ
４：ハードディスクコントローラ
５：ディスプレイコントローラ
６：ハードディスクドライブ
７：ＣＤ−ＲＯＭドライブ
８：ディスプレイ
１１：ＣＰＵとチップセットを繋ぐ信号線
１２：チップセットとＲＡＭを繋ぐ信号線
１３：チップセットと各種周辺機器とを繋ぐ周辺機器バス
１４：ハードディスクコントローラとハードディスクドライブを繋ぐ信号線
１５：ハードディスクコントローラとＣＤ−ＲＯＭドライブを繋ぐ信号線
１６：ディスプレイコントローラとディスプレイを繋ぐ信号線
【図１】
2004038314.tif 000003
【図２】
2004038314.tif 000004
【図３】
2004038314.tif 000005
【図４Ａ】
2004038314.tif 000006
【図４Ｂ】
2004038314.tif 000007
【図５】
2004038314.tif 000008
【図６】
2004038314.tif 000009
【図７】
2004038314.tif 000010
【図８Ａ】
2004038314.tif 000011
【図８Ｂ】
2004038314.tif 000012
【図９】
2004038314.tif 000013
【図１０】
2004038314.tif 000014
【図１１】
2004038314.tif 000015
【図１２】
2004038314.tif 000016
【図１３】
2004038314.tif 000017
【図１４】
2004038314.tif 000018
【図１５】
2004038314.tif 000019
【図１６】
2004038314.tif 000020
【図１７】
2004038314.tif 000021
【図１８】
2004038314.tif 000022
【図１９】
2004038314.tif 000023
【図２０】
2004038314.tif 000024
【図２１】
2004038314.tif 000025
【図２２】
2004038314.tif 000026
【図２３】
2004038314.tif 000027
【図２４】
2004038314.tif 000028
【図２５】
2004038314.tif 000029
【図２６】
2004038314.tif 000030
【図２７】
2004038314.tif 000031
【図２８】
2004038314.tif 000032
【図２９】
2004038314.tif 000033