(57)【特許請求の範囲】
【請求項１】
印刷部または撮像部を有するハードウェア資源を利用して画像情報処理にかかるアプリケーションと、前記アプリケーションから呼び出され前記ハードウェア資源の制御を行うサービス関数として定義される制御部とを記憶する記憶部と、プロセッサと、前記プロセッサが前記記憶部から前記アプリケーションと前記制御部とを読み出して、読み出した前記アプリケーションと前記制御部とをそれぞれプロセスとして実行し、前記アプリケーションのプロセスは、前記制御部に対して前記サービス関数の呼び出しを行って前記制御部から前記サービス関数の戻り値の受信を行うことにより前記制御部のプロセスとプロセス間通信を行う画像形成装置の前記アプリケーションを検証用に生成する画像形成装置用アプリケーション生成装置で実行される画像形成装置用アプリケーション生成方法であって、
前記画像形成装置用アプリケーション生成装置は、前記サービス関数の呼び出しの記述を含む前記アプリケーションのアプリソースファイルと、前記サービス関数の呼び出し処理と前記サービス関数の呼び出しの際の引数と戻り値に使用されるメモリ領域の状態遷移の正当性を検証する検証処理とを実行するサービス検証関数の前記呼び出し処理と前記検証処理と戻り値を返す復帰処理が記述された検証関数ソースファイルと、前記サービス関数のオブジェクト形式のファイルを登録したサービス関数ライブラリとを記憶する第２記憶部、を備え、
関数処理手段が、前記第２記憶部に記憶された前記ソースファイルを読み出して、読み出した前記アプリソースファイルの前記サービス関数の呼び出しの記述を、前記サービス検証関数の呼び出しの記述に置換する関数処理ステップと、
コード生成手段が、前記第２記憶部に記憶された前記検証関数ソースファイルを読み出して、前記関数処理ステップによって前記サービス検証関数の呼び出しの記述に置換された前記アプリソースファイルに読み出した前記検証関数ソースファイルを連結してコンパイルし、コンパイルにより生成されたオブジェクトファイルと前記第２の記憶部に記憶された前記サービス関数ライブラリとをリンクすることにより実行形式の前記アプリケーションを生成するコード生成ステップと、
を含んだことを特徴とする画像形成装置用アプリケーション生成方法。
【請求項２】
入力手段が、検証対象の前記サービス関数の呼び出しの記述が指定された設定情報の入力を受け付ける入力ステップをさらに含み、
前記関数処理ステップは、前記アプリソースファイルの前記サービス関数の呼び出しの記述の中から、前記設定情報に指定されたサービス関数の呼び出しの記述を、前記サービス検証関数の呼び出しの記述に置換することを特徴とする請求項１に記載の画像形成装置用アプリケーション生成方法。
【請求項３】
前記サービス検証関数は、前記メモリ領域に対する書き込みによる前記状態遷移を検証することを特徴とする請求項１または２に記載の画像形成装置用アプリケーション生成方法。
【請求項４】
前記サービス検証関数は、前記メモリ領域に対する読み込みによる前記状態遷移を検証することを特徴とする請求項１〜３のいずれか一つに記載の画像形成装置用アプリケーション生成方法。
【請求項５】
前記サービス検証関数は、前記メモリ領域の開放による前記状態遷移を検証することを特徴とする請求項１〜４のいずれか一つに記載の画像形成装置用アプリケーション生成方法。
【請求項６】
前記アプリソースファイルには、さらに、プログラミング言語で予め提供される汎用的な関数である標準関数の呼び出しが記述され、
前記第２記憶部は、さらに、前記標準関数の呼び出し処理と前記標準関数の呼び出しの際の引数と戻り値に使用されるメモリ領域の状態遷移の正当性を検証する検証処理と戻り値を返す復帰処理を実行する標準検証関数の前記呼び出し処理と前記検証処理と前記復帰処理とが記述された標準検証関数ソースファイルと、前記標準関数のオブジェクト形式のファイルを登録した標準関数ライブラリとを記憶し、
前記関数処理ステップは、さらに前記アプリソースファイルの前記標準関数の呼び出しの記述を、前記標準検証関数の呼び出しの記述に置換し、
前記コード生成ステップは、さらに、前記第２記憶部に記憶された前記標準関数ソースファイルを読み出して、前記関数処理ステップによって前記標準検証関数の呼び出しの記述に置換された前記アプリソースファイルに読み出した前記検証関数ソースファイルを連結してコンパイルし、コンパイルにより生成されたオブジェクトファイルと前記第２の記憶部に記憶された前記標準関数ライブラリとをリンクすることにより実行形式の前記アプリケーションを生成することを特徴とする請求項１〜５のいずれか一つに記載の画像形成装置用アプリケーション生成方法。
【請求項７】
前記第２記憶部は、さらに、前記サービス関数の呼び出しの際の引数と前記メモリ領域に対するアクセス方法とを対応付けた関数テーブルを記憶し、
検証関数コード生成手段が、前記第２記憶部から前記関数テーブルを参照して、前記アプリソースファイルの前記サービス関数の呼び出しの記述に対応する前記アクセス方法に基づいて、前記サービス検証関数ソースファイルを生成し、前記第２記憶部に保存する検証関数コード生成ステップ、
をさらに含んだことを特徴とする請求項１〜６のいずれか一つに記載の画像形成装置用アプリケーション生成方法。
【請求項８】
前記検証関数コード生成ステップは、前記サービス関数の処理内容に基づいて、前記メモリ領域に対する書き込みによる前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することを特徴とする請求項７に記載の画像形成装置用アプリケーション生成方法。
【請求項９】
前記検証関数コード生成ステップは、前記サービス関数の処理内容に基づいて、前記メモリ領域に対する読み込みによる前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することを特徴とする請求項７または８に記載の画像形成装置用アプリケーション生成方法。
【請求項１０】
前記検証関数コード生成ステップは、前記サービス関数の処理内容に基づいて、前記メモリ領域の開放による前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することを特徴とする請求項７〜９のいずれか一つに記載の画像形成装置用アプリケーション生成方法。
【請求項１１】
請求項１〜１０のいずれか一つに記載された方法をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、コピー、プリンタ、スキャナおよびファクシミリなどの画像形成処理にかかるユーザサービスを提供する画像形成装置に搭載するアプリケーションをデバッグ作業の検証のために生成する画像形成装置用アプリケーション生成方法およびその方法をコンピュータに実行させるプログラムに関するものである。
【０００２】
【従来の技術】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置（以下、「複合機」という。）が一般的に知られている。この複合機は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応する３種類のソフトウェアを設け、ソフトウェアの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
このような複合機では、画像データを生成して出力するため、メモリに対するアクセスが頻繁に生じてくる。このため、各ソフトウェアの開発段階において、メモリに対するアクセスが正常に行われているか否かを検証することが重要となる。
【０００４】
このようなメモリアクセスの検証を行う従来の方法としては、アプリケーションプログラムのソースファイルにおいて、プログラムがメモリに対して読み込み、書き込み、割り当て関数などの操作を行う箇所に、メモリアクセスを検証するための検証コード（タグ付け）を埋め込み、メモリアクセスが正常であるか否かを判断する方法が一般的に知られている。
【０００５】
【発明が解決しようとする課題】
しかしながら、このようなメモリアクセスの検証方法では、すべてのコンポーネントのソースコードが開示されている場合には、メモリアクセスを行うすべての箇所に検証コードを埋め込むことによりメモリアクセスが正常か否かを検証することができるが、一部のコンポーネントのソースコードが開示されていない場合には、非公開のコンポーネント内部で生じたメモリアクセスの障害を検証することができず、正確なデバッグ作業を行うことができないという問題がある。
【０００６】
例えば、あるソースコードが公開されているコンポーネントからＣ言語標準ライブラリとして文字列操作や入出力の標準関数のオブジェクトファイルだけが提供され、各関数のソースコードが公開されていない場合には、かかる標準関数の内部で行われるメモリアクセスについては検証することができない。
【０００７】
また、関数ライブラリとして提供されるすべてのコンポーネントのソースコードが公開されている場合でも、特定の関数ライブラリだけを除外したメモリアクセスの検証を行うと、除外した関数の内部でメモリアクセスエラーが生じている場合には、正確なデバッグ作業を行うことができない。
【０００８】
ここで、従来の複合機の場合、プリンタ、コピー、ファクシミリ、スキャナなどのアプリケーションプログラムはすべて複合機の生産者側で開発しており、サードベンダーなどの第三者が新規なアプリケーションを開発することは想定していないため、すべてのコンポーネントのソースコードは開発者に公開されている。また、従来の複合機では、プリンタ、コピー、ファクシミリ、スキャナなどの各機能単位でプロセスとして動作するアプリケーションプログラムを開発しているため、Ｃ言語標準ライブラリの標準関数などソースコードが公開されていないコンポーネントを利用する場合でも、メモリに対するアクセスが複雑になることはなく、デバッグ作業に支障をきたすことは少ない。
【０００９】
ところで、このような従来の複合機では、プリンタ、コピー、スキャナおよびファクシミリ装置に対応するソフトウェアをそれぞれ別個に設けているため、各ソフトウェアの開発に多大の時間を要する。このため、出願人は、表示部、印刷部および撮像部などの画像形成処理で使用されるハードウェア資源を有し、プリンタ、コピーまたはファクシミリなどの各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、これらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットホームを備えた画像形成装置（複合機）を発明した。
【００１０】
この複合機によれば、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行うプラットホームを備えた構成とすることによって、ソフトウェア開発の効率化を図るとともに、装置全体としての生産性を向上させることが可能となる。
【００１１】
このような新規な複合機では、アプリケーションのプロセスが機能ごとに複数存在するばかりか、アプリケーションの少なくとも２つが共通的に必要とするサービスを提供するコントロールサービスのプロセスが存在し、複合機内部には、従来の複合機に比べて非常に多くのプロセスが互いにプロセス間通信を行いながら並列実行されている。また、各プロセス内部には、複数のスレッドが起動されており、スレッドレベルでの並列実行を実現しながら他のプロセスとプロセス間通信を行ってユーザサービスの機能を実現している。すなわち、出願人が発明をした新規な複合機は、多数のプロセスやスレッドが複雑に絡み合って協働することによりコピー、プリンタ、スキャナ、ファクシミリなどの画像形成処理にかかるユーザサービスを提供するという特徴的な構成となっている。
【００１２】
このため、複合機の動作をより正確に検証するために、プロセス単位でデバッグ作業を行うよりも、多数のプロセスを協調動作させた状態でデバッグ作業を行う必要がある。このような複合機では多数のプロセスが動作しているため、複数のプロセスで共通にアクセス可能な共有メモリを用い、かかる共有メモリに対して多数のプロセスからアクセスを行っている。従って、従来の複合機におけるデバッグ作業とは異なり、多数のプロセスからの共有メモリへのアクセスを検証する必要性が生じてくる。このため、一部のソースコードが公開されていない関数などを利用する場合、当該関数内部でメモリアクセスエラーが生じた場合には、他のプロセスへの影響が大きく、従来の複合機に比べて正確なデバッグ作業を行うことができないという問題がある。
【００１３】
しかも、このような新規な複合機では、アプリケーションとコントロールサービスとを別個に設けているため、複合機の出荷後にユーザもしくは第三者であるサードベンダーが新規なアプリケーションを開発して複合機に搭載することを想定した構成となっている。このため、新規に開発したアプリケーションがコントロールサービスに提供される関数ライブラリを使用して関数呼び出しを行う場合に、関数の実行に伴ってメモリアクセスが正常に行われているか否かを検証することが必要となってくる。
【００１４】
しかしながら、コントロールサービスはハードウェア資源に近い層のモジュールであることから各コントロールサービスの処理手順を第三者に公開することは好ましくないため、コントロールサービスのソースプログラムを第三者に公開しない場合が多い。このため、新規アプリケーションの開発者は、自己の開発するアプリケーションのソースプログラムにメモリアクセスの検証コードを埋め込むことはできても、コントロールサービスのソースプログラムに検証コードを埋め込むことができず、この結果、メモリアクセス状態に矛盾が生じてしまい、新規アプリケーション開発においてメモリアクセスの検証を正確に行うことができないという、従来の複合機開発では問題にならなかった新規な課題が生じている。
【００１５】
この発明は上記に鑑みてなされたもので、多数のプロセスが動作する画像形成装置で動作するアプリケーションの開発において、メモリアクセスを正確に検証することができる画像形成装置用アプリケーション生成方法およびその方法をコンピュータに実行させるプログラムを得ることを目的とする。
【００１６】
【課題を解決するための手段】
上記目的を達成するため、請求項１にかかる発明は、印刷部または撮像部を有するハードウェア資源を利用して画像情報処理にかかるアプリケーションと、前記アプリケーションから呼び出され前記ハードウェア資源の制御を行うサービス関数として定義される制御部とを記憶する記憶部と、プロセッサと、前記プロセッサが前記記憶部から前記アプリケーションと前記制御部とを読み出して、読み出した前記アプリケーションと前記制御部とをそれぞれプロセスとして実行し、前記アプリケーションのプロセスは、前記制御部に対して前記サービス関数の呼び出しを行って前記制御部から前記サービス関数の戻り値の受信を行うことにより前記制御部のプロセスとプロセス間通信を行う画像形成装置の前記アプリケーションを検証用に生成する画像形成装置用アプリケーション生成装置で実行される画像形成装置用アプリケーション生成方法であって、前記画像形成装置用アプリケーション生成装置は、前記サービス関数の呼び出しの記述を含む前記アプリケーションのアプリソースファイルと、前記サービス関数の呼び出し処理と前記サービス関数の呼び出しの際の引数と戻り値に使用されるメモリ領域の状態遷移の正当性を検証する検証処理とを実行するサービス検証関数の前記呼び出し処理と前記検証処理と戻り値を返す復帰処理が記述された検証関数ソースファイルと、前記サービス関数のオブジェクト形式のファイルを登録したサービス関数ライブラリとを記憶する第２記憶部、を備え、関数処理手段が、前記第２記憶部に記憶された前記ソースファイルを読み出して、読み出した前記アプリソースファイルの前記サービス関数の呼び出しの記述を、前記サービス検証関数の呼び出しの記述に置換する関数処理ステップと、コード生成手段が、前記第２記憶部に記憶された前記検証関数ソースファイルを読み出して、前記関数処理ステップによって前記サービス検証関数の呼び出しの記述に置換された前記アプリソースファイルに読み出した前記検証関数ソースファイルを連結してコンパイルし、コンパイルにより生成されたオブジェクトファイルと前記第２の記憶部に記憶された前記サービス関数ライブラリとをリンクすることにより実行形式の前記アプリケーションを生成するコード生成ステップと、を含んだことを特徴とする。
【００１７】
この請求項１にかかる発明によれば、関数処理ステップによって、第２記憶部に記憶された前記ソースファイルを読み出して、読み出した前記アプリソースファイルの前記サービス関数の呼び出しの記述を、前記サービス検証関数の呼び出しの記述に置換する関数処理ステップと、コード生成ステップによって、前記第２記憶部に記憶された前記検証関数ソースファイルを読み出して、前記関数処理ステップによって前記サービス検証関数の呼び出しの記述に置換された前記アプリソースファイルに読み出した前記検証関数ソースファイルを連結してコンパイルし、コンパイルにより生成されたオブジェクトファイルと前記第２の記憶部に記憶された前記サービス関数ライブラリとをリンクすることにより実行形式の前記アプリケーションを生成することで、サービス関数のソースコードが公開されていない場合でも、サービス関数の機能を把握していれば、アプリケーションの実行時にサービス検証関数によってメモリアクセスによるメモリ状態を検証することができ、一部のソースコードが不明な場合でも正確なデバッグ作業を行うことができる。
また、この請求項１にかかる発明によれば、サービス検証関数によってサービス関数の呼び出しの際の引数と戻り値に使用されるメモリ領域の状態遷移の正当性を検証する検証処理とを実行することで、生成されたアプリケーションの実行時にメモリ確保アクセスが正当か否かをメモリ状態遷移によって把握することができるので、メモリ確保アクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができる。
【００１８】
また、請求項２にかかる発明は、入力手段が、検証対象の前記サービス関数の呼び出しの記述が指定された設定情報の入力を受け付ける入力ステップをさらに含み、
前記関数処理ステップは、前記アプリソースファイルの前記サービス関数の呼び出しの記述の中から、前記設定情報に指定されたサービス関数の呼び出しの記述を、前記サービス検証関数の呼び出しの記述に置換することを特徴とする。
【００１９】
この請求項２にかかる発明によれば、入力ステップによって、検証対象の前記サービス関数の呼び出しの記述が指定された設定情報の入力を受け付け、関数処理ステップによって、アプリソースファイルの前記サービス関数の呼び出しの記述の中から、前記設定情報に指定されたサービス関数の呼び出しの記述を、前記サービス検証関数の呼び出しの記述に置換することで、一部の関数のみにおけるメモリアクセスの検証を行うことができ、デバッグ作業を効率的に行うことができる。
【００２２】
また、請求項３にかかる発明は、前記サービス検証関数は、前記メモリ領域に対する書き込みによる前記状態遷移を検証することを特徴とする。
【００２３】
この請求項３にかかる発明によれば、サービス検証関数によってサービス検証関数は、前記メモリ領域に対する書き込みによる前記状態遷移を検証することで、生成されたアプリケーションの実行時にメモリ書き込みアクセスが正当か否かをメモリ状態遷移によって把握することができるので、メモリ書き込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができる。
【００２４】
また、請求項４にかかる発明は、前記サービス検証関数は、前記メモリ領域に対する読み込みによる前記状態遷移を検証することを特徴とすることを特徴とする。
【００２５】
この請求項４にかかる発明によれば、サービス検証関数によって前記メモリ領域に対する読み込みによる前記状態遷移を検証することで、生成されたアプリケーションの実行時にメモリ読み込みアクセスが正当か否かをメモリ状態遷移によって把握することができるので、メモリ読み込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができる。
【００２６】
また、請求項５にかかる発明は、前記サービス検証関数は、前記メモリ領域の開放による前記状態遷移を検証することを特徴とすることを特徴とする。
【００２７】
この請求項５にかかる発明によれば、サービス検証関数によって前記メモリ領域の開放による前記状態遷移を検証することを特徴とすることで、生成されたアプリケーションの実行時にメモリ開放アクセスが正当か否かをメモリ状態遷移によって把握することができるので、メモリ開放アクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができる。
【００２８】
また、請求項６にかかる発明は、前記アプリソースファイルには、さらに、プログラミング言語で予め提供される汎用的な関数である標準関数の呼び出しが記述され、前記第２記憶部は、さらに、前記標準関数の呼び出し処理と前記標準関数の呼び出しの際の引数と戻り値に使用されるメモリ領域の状態遷移の正当性を検証する検証処理と戻り値を返す復帰処理を実行する標準検証関数の前記呼び出し処理と前記検証処理と前記復帰処理とが記述された標準検証関数ソースファイルと、前記標準関数のオブジェクト形式のファイルを登録した標準関数ライブラリとを記憶し、前記関数処理ステップは、さらに前記アプリソースファイルの前記標準関数の呼び出しの記述を、前記標準検証関数の呼び出しの記述に置換し、前記コード生成ステップは、さらに、前記第２記憶部に記憶された前記標準関数ソースファイルを読み出して、前記関数処理ステップによって前記標準検証関数の呼び出しの記述に置換された前記アプリソースファイルに読み出した前記検証関数ソースファイルを連結してコンパイルし、コンパイルにより生成されたオブジェクトファイルと前記第２の記憶部に記憶された前記標準関数ライブラリとをリンクすることにより実行形式の前記アプリケーションを生成することを特徴とする。
【００２９】
この請求項６にかかる発明によれば、関数処理ステップによって、さらに、前記アプリソースファイルの前記標準関数の呼び出しの記述を、前記標準検証関数の呼び出しの記述に置換し、前記コード生成ステップは、さらに、前記第２記憶部に記憶された前記標準関数ソースファイルを読み出して、前記関数処理ステップによって前記標準検証関数の呼び出しの記述に置換された前記アプリソースファイルに読み出した前記検証関数ソースファイルを連結してコンパイルし、コンパイルにより生成されたオブジェクトファイルと前記第２の記憶部に記憶された前記標準関数ライブラリとをリンクすることにより実行形式の前記アプリケーションを生成することで、サービス関数だけでなく、ソースコードが公開されない標準関数からメモリアクセスを行う場合でも、標準関数の機能を把握していれば、アプリケーションの実行時に標準検証関数によってメモリアクセスによるメモリ状態を検証することができ、標準関数のライブラリのみが提供されている場合でも正確なデバッグ作業を行うことができる。
【００３０】
また、請求項７にかかる発明は、前記第２記憶部は、さらに、前記サービス関数の呼び出しの際の引数と前記メモリ領域に対するアクセス方法とを対応付けた関数テーブルを記憶し、検証関数コード生成手段が、前記第２記憶部から前記関数テーブルを参照して、前記アプリソースファイルの前記サービス関数の呼び出しの記述に対応する前記アクセス方法に基づいて、前記サービス検証関数ソースファイルを生成し、前記第２記憶部に保存する検証関数コード生成ステップ、をさらに含んだことを特徴とする。
【００３１】
この請求項７にかかる発明によれば、検証関数コード生成ステップによって、第２記憶部から前記関数テーブルを参照して、前記アプリソースファイルの前記サービス関数の呼び出しの記述に対応する前記アクセス方法に基づいて、前記サービス検証関数ソースファイルを生成し、前記第２記憶部に保存することで、サービス関数のソースコードが公開されていない場合でも、サービス検証関数ソースファイルをデバッグ作業者自ら作成する必要がない。このため、アプリケーションの実行時に、ソースファイルが自動生成されたサービス検証関数によってメモリアクセスによるメモリ状態を検証することができ、一部のソースコードが不明な場合でも正確なデバッグ作業を効率的に行うことができる。
【００３４】
また、請求項８にかかる発明は、前記検証関数コード生成ステップは、前記サービス関数の処理内容に基づいて、前記メモリ領域に対する書き込みによる前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することを特徴とすることを特徴とする。
【００３５】
この請求項８にかかる発明によれば、検証関数コード生成ステップによって、前記サービス関数の処理内容に基づいて、前記メモリ領域に対する書き込みによる前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することで、アプリケーションの実行時に、ソースファイルが自動生成されたメモリ書き込みアクセスを検証するサービス検証関数によって、メモリ書き込みアクセスが正当か否かをメモリ状態遷移によって把握することができるので、メモリ書き込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を効率的に行うことができる。
【００３６】
また、請求項９にかかる発明は、前記検証関数コード生成ステップは、前記サービス関数の処理内容に基づいて、前記メモリ領域に対する読み込みによる前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することを特徴とする。
【００３７】
この請求項９にかかる発明によれば、検証関数コード生成ステップによって、前記サービス関数の処理内容に基づいて、前記メモリ領域に対する読み込みによる前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することで、アプリケーションの実行時に、ソースファイルが自動生成されたメモリ読み込みアクセスを検証するサービス検証関数によって、メモリ読み込みアクセスが正当か否かをメモリ状態遷移によって把握することができるので、メモリ読み込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を効率的に行うことができる。
【００３８】
また、請求項１０にかかる発明は、前記検証関数コード生成ステップは、前記サービス関数の処理内容に基づいて、前記メモリ領域の開放による前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成する。
【００３９】
この請求項１０にかかる発明によれば、検証関数コード生成ステップによって、前記サービス関数の処理内容に基づいて、前記メモリ領域の開放による前記状態遷移を検証する前記サービス検証関数の呼び出しの記述を含む前記サービス検証関数ソースファイルを生成することで、アプリケーションの実行時に、ソースファイルが自動生成されたメモリ開放アクセスを検証するサービス検証関数によって、メモリ開放アクセスが正当か否かをメモリ状態遷移によって把握することができるので、メモリ開放アクセスによる障害を正確に検知することができ、より正確なデバッグ作業を効率的に行うことができる。
【００４２】
また、請求項１１にかかる発明は、請求項１〜１０のいずれか一つに記載された方法をコンピュータに実行させるプログラムであるので、請求項１〜１０のいずれか一つの動作をコンピュータによって実行することができる。
【００４３】
【発明の実施の形態】
以下に添付図面を参照して、この発明にかかる画像形成装置用アプリケーション生成方法およびその方法をコンピュータに実行させるプログラムの好適な実施の形態を詳細に説明する。
【００４４】
（実施の形態１）
図１は、この発明の実施の形態１であるデバッグ装置１００のソフトウェア構成を示すブロック図である。実施の形態１にかかるデバッグ装置１００は、画像形成装置（以下、「複合機」という。）で動作する新規アプリケーションをデバッグ用に生成し、その新規アプリケーションを複合機に搭載して起動させ、ネットワーク経由でアプリケーションからのメモリアクセスを検証するものである。実施の形態１にかかるデバッグ装置１００は、図１に示すように、デバッグ機能付きコンパイラ１１０と、リンカ１２０とから構成される。
【００４５】
デバッグ機能付きコンパイラ１１０は、ハードディスク（ＨＤ）１３０に格納されたアプリケーションのソースコードが記述されたソースファイル１３１を、コマンドの指定に従って、検証コード（以下、「タグ」という。）や後述するオーバロードタグ関数処理を行って、アプリケーションのオブジェクトコードからなるオブジェクトファイルを生成するものである。デバッグ機能付きコンパイラ１１０は、図１に示すように、さらにコマンド解析部１１１と、構文解析部１１２と、オーバロードタグ関数処理部１１３と、タグ付加部１１４と、コード生成部１１５とから構成される。ここで、オーバロードタグ関数は、本発明におけるサービス検証関数および標準検証関数を構成する。
【００４６】
ＨＤ（ハードディスク）１３０には、アプリケーションのＣ言語ソースコードが記述されたソースファイル１３１と、後述するオーバロードタグ関数が指定されたＸＭＬ（ｅＸｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式のオーバロードタグ関数設定ファイル１３３と、Ｃ言語ソースコードでオーバロードタグ関数宣言が記述されたオーバロードタグ関数インクルードファイル１３４と、Ｃ言語ソースコードでオーバロードタグ関数の処理が記述されたオーバロードタグ関数ソースファイル１３５が格納されている。また、ＨＤ１３０には、デバッグ機能付きコンパイラ１１０によって一時的に、サービス関数および標準関数をオーバロードタグ関数に置換された中間ソースファイル１３８、およびソースファイル１３１または中間ソースファイル１３８から生成されたオブジェクトファイル１３９が生成され、さらにリンカ１２０によってアプリケーションのデバッグ用実行形式ファイル１３２が生成される。
【００４７】
オーバロードタグ関数設定ファイル１３３は、本発明における設定情報を構成するものであり、ユーザによって作成される。このオーバロードタグ関数設定ファイル１３３には、オーバロードタグ関数に置換する関数の指定、オーバロードタグ関数インクルードファイル名およびオーバロードタグ関数ソースファイル名の指定、オーバロードタグ関数インクルードファイル１３４とオーバロードタグ関数ソースファイル１３５の格納先ディレクトリの指定がされる。
【００４８】
デバッグ機能付きコンパイラ１１０のコマンド解析部１１１は、ユーザからキーボードなどの入力装置によって入力されたコマンドのパラメータや構文の解析を行って、入力されたコマンドが文法的に正確か否かを判断するものである。
【００４９】
構文解析部１１２は、ＨＤ１３０に格納されたアプリケーションのソースファイル１３１を入力して、ソースファイル１３１に記述されたＣ言語ソースコードを、Ｃ言語文法に従って解析し、導出木や構文木などを生成するものであり、通常のコンパイラにおける構文解析と同様の処理を行う。
【００５０】
オーバロードタグ関数処理部１１３は、ソースファイル１３１に記述された関数の中からオーバロードタグ関数設定ファイル１３３にデバッグ対象として設定されているコントロールサービスの関数やＣ言語標準関数を、対応するオーバロードタグ関数に置換した中間ソースファイル１３８を生成するものである。タグ付加部１１４は、ソースファイル１３１に記述された関数の入口と出口にメモリアクセス検証コードであるタグを付加した中間ソースファイル１３８を生成するものである。
【００５１】
コード生成部１１５は、オーバロードタグ関数設定ファイル１３３によるオーバロードタグ関数指定がある場合には、タグ付加部１１４によってタグを付加されたアプリケーションの中間ソースファイル１３８を、オブジェクトコードからなるアプリケーションのオブジェクトファイル１３９を生成する。さらに、コード生成部１１５は、オーバロードタグ関数処理部１１３によってサービス関数および標準関数をオーバロードタグ関数に置換した中間ソースファイル１３８と、オーバロードタグ関数インクルードファイル１３４と、オーバロードタグ関数ソースファイル１３５と、一ファイルに結合して、オブジェクトコードからなるアプリケーションのオブジェクトファイル１３９を生成する。
【００５２】
リンカ１２０は、コード生成部１１５によって生成されたオブジェクトファイル１３９と、ＨＤ１３０に格納されているコントロールサービス関数ライブラリ１３６および標準関数ライブラリ１３７とをリンク（結合）して、複合機およびコンピュータのＯＳ上で実行可能なアプリケーションのデバッグ用実行形式ファイル１３２を生成するものである。
【００５３】
図２は、実施の形態１にかかるデバッグ装置１００のハードウェア構成を示すブロック図である。図２に示すように、このデバッグ装置１００は、ＣＰＵなどの制御装置２０３と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０５と、ＨＤ１３０と、ディスプレイ装置などの表示装置２０２と、キーボードやマウスなどの入力装置２０１と、ＬＡＮボードやモデムなどの通信装置２０４とを備えており、ＰＣ（Personal Computer）、ワークステーションなどのコンピュータを利用した通常の構成である。このデバッグ装置１００は、ＬＡＮ２０６などのネットワークによって画像形成装置（以下、「複合機」という。）３００と接続されており、デバッグ装置１００からネットワーク上の複合機３００のデバッグを行うようになっている。
【００５４】
上記デバッグ機能付きコンパイラ１１０の各部およびリンカ１２０は、このデバッグ用アプリケーション生成プログラムを実行したときに、ＲＡＭ２０５上に生成されて実行される。このデバッグ用アプリケーション生成プログラムは、ソフトウェア開発キット（ＳＤＫ：Ｓｏｆｔｗａｒｅ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ｋｉｔ）などの開発用ツールキットの一部または全部として、ＣＤ−ＲＯＭまたはＦＤなどの記憶媒体に実行可能な形式またはインストール可能な形式のファイルで提供される。また、このような実行可能な形式またはインストール可能な形式のファイルを、ネットワーク経由で取得可能な方法で提供するようにしても良い。
【００５５】
次に、デバッグ対象である複合機３００について説明する。図３は、複合機３００の機能的構成を示すブロック図である。図３に示すように、複合機３００は、白黒ラインプリンタ（B&W LP）３０１と、カラーラインプリンタ（Color LP）３０２と、スキャナ、ファクシミリ、ハードディスク（ＨＤ）、メモリ、ネットワークインタフェースなどのハードウェアリソース３０３を有するとともに、プラットホーム３２０とアプリケーション３３０とから構成されるソフトウェア群３１０とを備えている。
【００５６】
プラットホーム３２０は、アプリケーション３３０からの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一または複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ（ＳＲＭ）３２３と、汎用ＯＳ３２１とを備えている。
【００５７】
コントロールサービスは、複数のサービスモジュールから形成され、ＳＣＳ（システムコントロールサービス）３２２と、ＥＣＳ（エンジンコントロールサービス）３２４と、ＭＣＳ（メモリコントロールサービス）３２５と、ＯＣＳ（オペレーションパネルコントロールサービス）３２６と、ＦＣＳ（ファックスコントロールサービス）３２７と、ＮＣＳ（ネットワークコントロールサービス）３２８とから構成される。なお、このプラットホーム３２０は、あらかじめ定義された関数により前記アプリケーション３３０から処理要求を受信可能とするアプリケーションプログラミングインタフェース（ＡＰＩ）を有する。
【００５８】
汎用ＯＳ３２１は、ＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、プラットホーム３２０並びにアプリケーション３３０の各ソフトウェアをそれぞれプロセスとして並列実行する。
【００５９】
ＳＲＭ３２３のプロセスは、ＳＣＳ３２２とともにシステムの制御およびリソースの管理を行うものである。ＳＲＭ３２３のプロセスは、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４  Ｉ／Ｆ、ＲＳ２３２Ｃ  Ｉ／Ｆなど）のハードウェア資源を利用する上位層からの要求に従って調停を行い、実行制御する。
【００６０】
具体的には、このＳＲＭ３２３は、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、ＳＲＭ３２３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容（例えば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。
【００６１】
ＳＣＳ３２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御などを行う。
【００６２】
ＥＣＳ３２４のプロセスは、白黒ラインプリンタ（B&W LP）３０１、カラーラインプリンタ（Color LP）３０２、スキャナ、ファクシミリなどからなるハードウェアリソース３０３のエンジンの制御を行う。
【００６３】
ＭＣＳ３２５のプロセスは、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などを行う。
【００６４】
ＦＣＳ３２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供する。
【００６５】
ＮＣＳ３２８のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行う。具体的には、ftpd、httpd、lpd、snmpd、telnetd、smtpdなどのサーバデーモンや、同プロトコルのクライアント機能などを有している。
【００６６】
ＯＣＳ３２６は、オペレータ（ユーザ）と本体制御間の情報伝達手段となるオペレーションパネル（操作パネル）の制御を行う。ＯＣＳ３２６は、オペレーションパネルからキー押下をキーイベントとして取得し、取得したキーに対応したキーイベント関数をＳＣＳ３２２に送信するＯＣＳプロセスの部分と、アプリケーション３３０またはコントロールサービスからの要求によりオペレーションパネルに各種画面を描画出力する描画関数やその他オペレーションパネルに対する制御を行う関数などがあらかじめ登録されたＯＣＳライブラリの部分とから構成される。このＯＣＳライブラリは、アプリケーション３３０およびコントロールサービスの各モジュールにリンクされて実装されている。なお、ＯＣＳ３２６のすべてをプロセスとして動作させるように構成しても良く、あるいはＯＣＳ３２６のすべてをＯＣＳライブラリとして構成しても良い。
【００６７】
アプリケーション３３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ３１１と、コピー用アプリケーションであるコピーアプリ３１２と、ファクシミリ用アプリケーションであるファックスアプリ３１３と、スキャナ用アプリケーションであるスキャナアプリ３１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ３１５と、工程検査用アプリケーションである工程検査アプリ３１６とを有している。これらのアプリケーション３３０はいずれも複合機３００の起動時に初期化部（図示せず）によりプロセスとして生成され、動作する。
【００６８】
アプリケーション３３０の各プロセス、コントロールサービスの各プロセスは、関数呼び出しとその戻り値送信およびメッセージの送受信によってプロセス間通信を行いながら、コピー、プリンタ、スキャナ、ファクシミリなどの画像形成処理にかかるユーザサービスを実現している。
【００６９】
このように、実施の形態１にかかる複合機３００には、複数のアプリケーション３３０および複数のコントロールサービスが存在し、いずれもプロセスとして動作している。そして、これらの各プロセス内部には、一または複数のスレッドが生成されて、スレッド単位の並列実行が行われる。そして、コントロールサービスがアプリケーション３３０に対し共通サービスを提供しており、このため、これらの多数のプロセスが並列動作、およびスレッドの並列動作を行って互いにプロセス間通信を行って協調動作をしながら、コピー、プリンタ、スキャナ、ファクシミリなどの画像形成処理にかかるユーザサービスを提供するようになっている。
【００７０】
そして、複合機３００には、サードベンダーなどの第三者がコントロールサービス層の上のアプリケーション層に新規なアプリケーション（新規アプリ３１７）を開発して搭載することが可能となっている。実施の形態１にかかるデバッグ装置１００は、この新規アプリ３１７の開発段階で、メモリアクセスを検証するためにデバッグ作業を行うようになっている。
【００７１】
図４は、新規アプリ３１７とコントロールサービスの関数呼び出しの関係を示すブロック図である。すなわち、新規アプリ３１７のプロセスからコントロールサービスのプロセス（図４ではＥＣＳ３２４）に対してＡＰＩ（アプリケーションプログラミングインタフェース）を利用してコントロールサービスで提供される関数の呼び出し（図４ではｅｃｓ＿ｆｕｎｃ関数）によるプロセス間通信を行った場合に、コントロールサービス側で呼び出された関数が実行される。
【００７２】
このとき、この関数実行に伴ってメモリに対する領域確保、メモリに対するリード／ライト、あるいはメモリの領域解放が行われた場合に、かかるメモリアクセスによるメモリ領域の状態遷移が正常か否かを判断するようになっている。このような場合、オーバロードタグ関数を使用せずに、メモリアクセス検証コードであるタグを新規アプリ３１７およびコントロールサービスのメモリアクセスを行う箇所に付加すればメモリアクセスの検証を行うことも可能である。しかしながら、実施の形態１にかかる複合機３００では、コントロールサービスが提供する関数は関数ライブラリというオブジェクトコードでのみ提供し、提供する各関数のソースコードは第三者に公開していないため、タグ付けによりメモリアクセスの検証を行えず、このためオーバロードタグ関数を用いたメモリアクセスの検証を行っている。
【００７３】
次に、以上のように構成された実施の形態１にかかるデバッグ装置１００およびデバッグ用アプリケーション生成プログラムによるデバッグ用新規アプリの生成およびメモリアクセス検証方法について説明する。図５は、デバッグ用新規アプリの生成処理において、使用および生成されるファイルと、デバッグ用新規アプリの全体の流れを示した説明図である。
【００７４】
新規アプリのデバッグ作業を行うユーザは、デバッグ用新規アプリの実行形式ファイルを生成するために、デバッグ装置１００のキーボードなどの入力装置２０１から、コマンドプロンプト％で次のコマンドを入力する。
【００７５】
％  ｄｂｇｃｃ  ソースファイル名  −ｏ  実行形式ファイル名
ここで、「ｄｂｇｃｃ」は、デバッグ機能付きコンパイラおよびリンカの起動の指定を、「ソースファイル名」は新規アプリのソースファイル名を、「−ｏ  実行形式ファイル名」は新規アプリの実行形式ファイル名を示す。また、かかるコマンドの実行時に、環境変数ＯＶＲ＿ＸＭＬに何も設定されていない場合には、新規アプリのソースファイルの中の関数の入口および出口にメモリアクセス検証コードであるタグを付加する処理が行われて、実行形式ファイルが生成される。
【００７６】
一方、環境変数ＯＶＲ＿ＸＭＬにオーバロードタグ関数設定ファイル名が設定されている場合には、オーバロードタグ関数を利用したメモリアクセス検証が可能な実行形式ファイルが生成されるようになっている。例えば、図５の例では、次のような環境変数の設定およびコマンド入力することにより、オーバロードタグ関数を利用した新規アプリの実行形式ファイルの生成処理が開始される。
【００７７】
環境変数ＯＶＲ＿ＸＭＬ＝”ｎｅｗａｐｐｌ．ｘｍｌ”
％  ｄｂｇｃｃ  ｎｅｗａｐｐｌ．ｃ  −ｏ  ｎｅｗａｐｐｌ．ｅｘｅ
【００７８】
図５の例では、新規アプリ３１７がコントロールサービスとしてＥＣＳ１２４のプロセスとプロセス間通信を行う場合において、ＥＣＳ３２４で提供される関数ｅｃｓ＿ｊｏｂｍｏｄｅ（）を呼び出し、ｅｃｓ＿ｊｏｂｍｏｄｅ（）の中で行われるメモリアクセスのメモリ状態を検証するとともに、標準関数ｓｔｒｃｐｙ（）の中で行われるメモリアクセスのメモリ状態を検証するデバッグ用新規アプリを生成するものである。ここで、ｅｃｓ＿ｊｏｂｍｏｄｅ（）が登録されているＥＣＳ関数ライブラリ１３６（ｅｃｓ．ｌｉｂ）とｓｔｒｃｐｙ（）が登録されている標準関数ライブラリ１３７（ｓｔａｎｄａｒｄ．ｌｉｂ）はいずれもオブジェクトファイルとしてユーザに提供されており、従って、ｅｃｓ＿ｊｏｂｍｏｄｅ（）とｓｔｒｃｐｙ（）のソースコードは公開されておらず、かかる関数のソースコードにタグ付けを行うことは不可能である。このため、図５の例では、オーバロードタグ関数を利用することでメモリアクセス検証を可能としている。
【００７９】
オーバロードタグ関数設定ファイル１３３（ｎｅｗａｐｐｌ．ｘｍｌ）には、オーバロードタグ関数インクルードファイル１３４（ｅｃｓ＿ｏｖｒｌｆｕｎｃ．ｈ）およびオーバロードタグ関数ソースファイル１３５（ｅｃｓ＿ｏｖｒｌｆｕｎｃ．ｃ）の指定と、オーバロードタグ関数に置換する関数ｅｃｓ＿ｊｏｂｍｏｄｅおよびｓｔｒｃｐｙの指定がなされている。
【００８０】
図６は、図５の例におけるオーバロードタグ関数設定ファイル１３３の内容を示す説明図である。このオーバロードタグ関数設定ファイル１３３はデバッグ作業の開始前にユーザによって作成される。
【００８１】
図５に示すように、タグ＜ｄｂｇｃｃ＞の属性「ｐａｔｈ」にはオーバロードタグ関数インクルードファイル１３４とオーバロードタグ関数ソースファイル１３５のディレクリトリパスを指定する。また、タグ＜ｉｎｃｆｉｌｅ＞の属性「ｓｏｕｒｃｅ」にはオーバロードタグ関数ソースファイル１３５のファイル名（ｅｃｓ＿ｏｖｒｌｆｕｎｃ．ｃ）を、属性「ｉｎｃｌｕｄｅ」にはオーバロードタグ関数インクルードファイル１３４のファイル名（ｅｃｓ＿ｏｖｒｌｆｕｎｃ．ｈ）を指定する。タグ＜ｆｕｎｃ＞には、オーバロードタグ関数に置換する対象となる関数名、すなわち、メモリアクセス検証を行う関数名を指定する。図５および図６の例では、「ｅｃｓ＿ｊｏｂｍｏｄｅ」と「ｓｔｒｃｐｙ」をタグ＜ｆｕｎｃ＞にそれぞれ指定する。
【００８２】
図７は、デバッグ用新規アプリの生成処理の手順を示すフローチャートである。なお、以下、図５の各ファイルを例にあげて説明する。ユーザが環境変数ＯＶＲ＿ＸＭＬにオーバロードタグ関数設定ファイル１３３（ｎｅｗａｐｐｌ．ｘｍｌ）を設定して、コマンドｄｂｇｃｃを引数に新規アプリソースファイル（ｎｅｗａｐｐｌ．ｃ）を指定して起動すると、まずデバッグ機能付きコンパイラ１１０が起動し、コマンド解析部１１１によって入力されたコマンドの解析を行う（ステップＳ７０１）。具体的にはパラメータや構文の解析を行って、入力されたコマンドが文法的に正確か否かを判断する。
【００８３】
次に、構文解析部１１２によって、新規アプリのソースファイル１３１（ｎｅｗａｐｐｌ．ｃ）を読み込み（ステップＳ７０２）、ソースファイル１３１に記述されたＣ言語ソースコードの構文解析を行う（ステップＳ７０３）。具体的には、構文解析部１１２は、Ｃ言語ソースコードをＣ言語文法に従って解析し、導出木や構文木などを生成する。
【００８４】
そして、コマンド解析部１１１によって、環境変数ＯＶＲ＿ＸＭＬの設定内容を調べる（ステップＳ７０４）。そして、環境変数ＯＶＲ＿ＸＭＬに何も設定されていない場合には、オーバロードタグ関数の処理は行わず、ソースファイル１３１の関数の入口と出口にメモリアクセス検証コードとしてタグを付加し（ステップＳ７０６）、タグ付けされたソースファイル１３１から新規アプリのオブジェクトコードを生成し、オブジェクトファイル１３９としてＨＤ１３０に格納する（ステップＳ７０７）。
【００８５】
一方、ステップＳ７０４において、環境変数ＯＶＲ＿ＸＭＬにオーバロードタグ関数設定ファイル１３３のファイル名（ｎｅｗａｐｐｌ．ｘｍｌ）が設定されている場合には、オーバロードタグ関数処理部１１３によるオーバロードタグ関数処理とコード生成部１１５によるコード生成処理を行って、新規アプリのオブジェクトコードを生成し、オブジェクトファイル１３９としてＨＤ１３０に格納する（ステップＳ７０５）。
【００８６】
そして、生成された新規アプリ３１７のオブジェクトコードで記述されたオブジェクトファイル１３９と、ＥＣＳ関数ライブラリ１３６と、標準関数ライブラリ１３７とをリンクして、デバッグ用新規アプリ３１７の実行形式ファイル１３２を生成する（ステップＳ７０８）。
【００８７】
次に、上述のステップＳ７０５で行われるオーバロードタグ関数処理およびコード生成処理について説明する。図８は、オーバロードタグ関数処理およびコード生成処理の手順を示すフローチャートである。
【００８８】
まず、オーバロードタグ関数処理部１１３によって、環境変数ＯＶＲ＿ＸＭＬに設定されたオーバロードタグ関数設定ファイル１３３（ｎｅｗａｐｐｌ．ｘｍｌ）を読み込む（ステップＳ８０１）。そして、オーバロードタグ関数処理部１１３は、オーバロードタグ関数設定ファイル１３３（ｎｅｗａｐｐｌ．ｘｍｌ）の＜ｆｕｎｃ＞タグを参照し、オーバロードタグ関数に置換する関数を全てリストアップする（ステップＳ８０２）。そして、ＨＤ１３０に中間ソースファイル１３８を生成し、ソースファイル１３１（ｎｅｗａｐｐｌ．ｃ）の内容を中間ソースファイル１３８にコピーする（ステップＳ８０３）。
【００８９】
ついで、オーバロードタグ関数処理部１１３は、図５に示すように、ソースファイル１３１（ｎｅｗａｐｐｌ．ｃ）からコピーされた中間ソースファイル１３８の中で、＜ｆｕｎｃ＞タグで指定された関数名「ｅｃｓ＿ｊｏｂｍｏｄｅ」をオーバーロードタグ関数「ｅｃｓ＿ｊｏｂｍｏｄｅ＿」に置換する（ステップＳ８０４）。なお、オーバロードタグ関数名は、図５に示すようにソースファイル１３１に記述された関数名の後ろに「＿」を付加したものとして定めているが、各関数ごとに対応したオーバロードタグ関数を設ければオーバロードタグ関数の名称は任意に定めることができる。
【００９０】
置換の際、オーバーロードタグ関数ｅｃｓ＿ｊｏｂｍｏｄｅ＿の第１引数と第２引数を付加し、第３引数以降に、元の関数ｅｃｓ＿ｊｏｂｍｏｄｅの引数を記述する。ここで、オーバーロードタグ関数の第１引数は、検証結果の表示のために、ソースファイル名（ｎｅｗａｐｐｌ．ｃ）を指定し、第２引数はソースファイル１３１における置換された関数の行数であり、これも検証結果の表示のために指定される。
【００９１】
このような関数のオーバロードタグ関数への置換を、ステップＳ８０２でリストアップされたすべての関数に対して繰り返し行う（ステップＳ８０５）。これにより、図５に示すように、標準関数ｓｔｒｃｐｙもオーバロードタグ関数ｓｔｒｃｐｙ＿に、ＥＣＳサービス関数ｅｃｓ＿ｍｓｇａｌｌｏｃもオーバロードタグ関数ｅｃｓ＿ｍｓｇａｌｌｏｃ＿に置換される。
【００９２】
次に、コード生成部１１５によって、オーバロードタグ関数設定ファイル１３３（ｎｅｗａｐｐｌ．ｘｍｌ）の＜ｄｂｇｃｃ＞タグの属性「ｐａｔｈ」からオーバロードタグ関数インクルードファイル１３４とオーバロードタグ関数ソースファイル１３５のディレクトリパスを、＜ｉｎｃｆｉｌｅ＞タグの属性「ｉｎｃｌｕｄｅ」からオーバロードタグ関数インクルードファイル名をそれぞれ取得し、中間ソースファイル１３８の先頭にオーバロードタグ関数インクルードファイル１３４（ｅｃｓ＿ｏｖｒｌｆｕｎｃ．ｈ）を挿入する（ステップＳ８０６）。また、コード生成部１１５によって、＜ｉｎｃｆｉｌｅ＞タグの属性「ｓｏｕｒｃｅ」からオーバロードタグ関数ソースファイル名を取得し、中間ソースファイル１３８の後ろにオーバロードタグ関数ソースファイル１３５（ｅｃｓ＿ｏｖｒｌｆｕｎｃ．ｃ）を挿入する（ステップＳ８０７）。
【００９３】
そして、コード生成部１１５は、オーバロードタグ関数インクルードファイル１３４およびオーバロードタグ関数ソースファイル１３５が挿入された中間ソースファイル１３８のソースコードを、通常のコンパイラと同様の処理手順でオブジェクトコードに変換し、デバッグ用新規アプリのオブジェクトファイル１３９（ｎｅｗａｐｐｌ．ｏ）を生成する（ステップＳ８０８）。このオブジェクトファイル１３９は、図７のステップＳ７０８で説明したとおり、リンカ１２０によってＥＣＳ関数ライブラリ１３６（ｅｃｓ．ｌｉｂ）と標準関数ライブラリ１３７（ｓｔａｎｄａｒｄ．ｌｉｂ）とリンクされて、デバッグ用新規アプリの実行形式ファイル１３２（ｎｅｗａｐｐｌ．ｅｘｅ）が生成される。
【００９４】
次に、オーバロードタグ関数ソースファイル１３５について詳細に説明する。実施の形態１のデバッグ装置１００では、オーバロードタグ関数ソースファイル１３５はユーザがｄｂｇｃｃコマンドの実行前にあらかじめ作成しておく必要がある。図９は、オーバロードタグ関数ソースファイル１３５の詳細の一例を示す説明図である。図９は、図５に示したオーバロードタグ関数ソースファイル１３５において、さらにメモリアクセス追跡処理の部分を詳細に示したものである。
【００９５】
オーバロードタグ関数では、まず置換元の関数を実行した後、かかる関数のメモリアクセスの処理内容に応じて、メモリの状態遷移をチェックするメモリ追跡処理が実行される。
【００９６】
ここで、メモリ領域の状態遷移について説明する。図１０は、メモリの状態遷移とメモリアクセスの関係を示す説明図である。図１０において、初期状態とは、そのメモリに領域確保も初期化もされていない状態であり、初期状態のメモリに対してはメモリ確保アクセスが可能であるが、他のアクセスが行われるとエラーとなる。確保状態とは、メモリに領域確保がされているが、まだ初期化されていない状態である。確保状態のメモリに対しては、開放または書き込みアクセスが可能であるが、他のアクセスが行われるとエラーとなる。書き込み状態とはメモリに領域確保され、かつ初期化されている状態である。書き込み状態のメモリに対しては、書き込みアクセス、読み込みアクセスおよび開放アクセスが可能であるが、他のアクセスが行われるとエラーとなる。
【００９７】
また、メモリの状態遷移については次の通りである。図１０に示すように、初期状態のメモリに確保アクセスをおこなうとメモリは確保状態となる。また、確保状態のメモリに書き込みアクセスを行うとメモリは書き込み状態となる。書き込み状態のメモリに読み込みアクセスまたは書き込みアクセスを行うと、メモリは書き込み状態を維持したままである。確保状態または書き込み状態のメモリに開放アクセスを行うと、メモリは初期状態となる。実施の形態１にかかるデバッグ装置１００で実行されるデバッグ用アプリケーション生成プログラムは、かかる状態遷移を検査するために、メモリの状態遷移を検査する次のメモリ状態イベント関数を備えている。ここで、第１引数ａｄｄｒは、検査対象のメモリ領域の先頭アドレスであり、第２引数は検査対象のメモリ領域のサイズを示している。
【００９８】
（１）ｅｖｅｎｔ＿ａｌｌｏｃ（ｃｈａｒ＊  ａｄｄｒ，ｉｎｔ  ｓｉｚｅ）
メモリアドレスａｄｄｒからｓｉｚｅバイトの範囲の領域にメモリ確保イベントを生成し、メモリ状態遷移が正常か否かを検査するものである。メモリ状態が、初期状態から確保状態に遷移している場合には正常の戻り値を返し、かかる遷移以外の場合には異常の戻り値を返す。異常の戻り値は、遷移元の状態によって異なる戻り値としている。
【００９９】
（２）ｅｖｅｎｔ＿ｒｅａｄ（ｃｈａｒ＊  ａｄｄｒ，ｉｎｔ  ｓｉｚｅ）
メモリアドレスａｄｄｒからｓｉｚｅバイトの範囲の領域にメモリ読み込みイベントを生成し、メモリ状態遷移が正常か否かを検査するものである。メモリ状態が、書き込み状態から書き込み状態に遷移している場合には正常の戻り値を返し、かかる遷移以外の場合には異常の戻り値を返す。異常の戻り値は、遷移元の状態によって異なる戻り値としている。
【０１００】
（３）ｅｖｅｎｔ＿ｗｒｉｔｅ（ｃｈａｒ＊  ａｄｄｒ，ｉｎｔ  ｓｉｚｅ）
メモリアドレスａｄｄｒからｓｉｚｅバイトの範囲の領域にメモリ書き込みイベントを生成し、メモリ状態遷移が正常か否かを検査するものである。メモリ状態が、書き込み状態から書き込み状態に遷移している場合あるいは確保状態から書き込み状態に遷移している場合には正常の戻り値を返し、かかる遷移以外の場合には異常の戻り値を返す。異常の戻り値は、遷移元の状態によって異なる戻り値としている。
【０１０１】
（４）ｅｖｅｎｔ＿ｆｒｅｅ（ｃｈａｒ＊  ａｄｄｒ，ｉｎｔ  ｓｉｚｅ）
メモリアドレスａｄｄｒからｓｉｚｅバイトの範囲の領域にメモリ開放イベントを生成し、メモリ状態遷移が正常か否かを検査するものである。メモリ状態が、確保状態から初期状態に遷移している場合あるいは書き込み状態から初期状態に遷移している場合には正常の戻り値を返し、かかる遷移以外の場合には異常の戻り値を返す。異常の戻り値は、遷移元の状態によって異なる戻り値としている。
【０１０２】
なお、上記各メモリ状態イベント関数は、上記範囲の領域に対しメモリの現在の状態と遷移前の状態を得るＯＳのシステムコールを発行して、遷移前および遷移後をメモリ状態の取得している。図９のオーバロードタグ関数の例では、置換元のｅｃｓ＿ｊｏｂｍｏｄｅ関数は引数のポインタｐａｒａ１およびポインタｐａｒａ２が指すメモリ領域の内容をｒｅａｄする処理を行った上で、ｐｉｄで指定されたプロセスＩＤのプロセスに対しジョブモード設定処理を行うＥＣＳのサービス関数である。このため、ｅｃｓ＿ｊｏｂｍｏｄｅ関数に対応するオーバロードタグ関数ｅｃｓ＿ｊｏｂｍｏｄｅ＿では、図９に示すように、まず置換元のｅｃｓ＿ｊｏｂｍｏｄｅ関数を実行した後、ｐａｒａ１およびポインタｐａｒａ２の指す各メモリ領域に対し、ｅｖｅｎｔ＿ｒｅａｄのメモリ状態イベント関数を発行して各メモリ領域の状態遷移をチェックしている。
【０１０３】
また、置換元のｓｔｒｃｐｙ関数は引数のポインタｓｒｃが指す領域の内容を引数ｄｅｓｔポインタで示される領域にコピーする処理を標準関数である。このため、ｓｔｒｃｐｙ関数に対応するオーバロードタグ関数ｓｔｒｃｐｙ＿では、図９に示すように、まず置換元のｓｔｒｃｐｙ関数を実行した後、ｓｒｃの指すメモリ領域に対し、ｅｖｅｎｔ＿ｒｅａｄのメモリ状態イベント関数を発行し、ｄｅｓｔの指すメモリ領域に対し、ｅｖｅｎｔ＿ｗｒｉｔｅのメモリ状態イベント関数を発行して各メモリ領域の状態遷移をチェックしている。
【０１０４】
また、置換元のｅｃｓ＿ｍｓｇａｌｌｏｃ関数は引数のポインタｍｓｇ＿ａｒｅａが指す領域をメッセージ領域として確保する処理をＥＣＳのサービス関数である。このため、ｅｃｓ＿ｍｓｇａｌｌｏｃ関数に対応するオーバロードタグ関数ｅｃｓ＿ｍｓｇａｌｌｏｃ＿では、図９に示すように、まず置換元のｅｃｓ＿ｍｓｇａｌｌｏｃ関数を実行した後、ｍｓｇ＿ａｒｅａの指すメモリ領域に対し、ｅｖｅｎｔ＿ａｌｌｏｃのメモリ状態イベント関数を発行しメモリ領域の状態遷移をチェックしている。
【０１０５】
従って、デバッグ用の新規アプリ３１７の実行形式ファイル１３２を実行すると、上述したオーバロードタグ関数によって、メモリの状態遷移がチェックされ、異常な場合にはエラー表示がなされるので、プログラムの一部の箇所、一部の関数のみのメモリアクセスの検証を矛盾を生じずに行うことができる。
【０１０６】
これらの各関数の引数ポインタで示されるメモリ領域は、いずれも関数外部で確保されるメモリ領域であり、かかるオーバロードタグ関数を利用することにより、関数内部でアクセスされるメモリ領域の他、関数内部のメモリ領域と区別して関数外部でアクセスされるメモリ領域に対してもメモリアクセスの検証を行うことが可能となっている。
【０１０７】
このように実施の形態１にかかるデバッグ装置１００およびデバッグ用アプリケーション生成プログラムでは、オーバロードタグ関数処理部１１３によって、新規アプリソースファイル１３１のコントロールサービス関数を、オーバロードタグ関数に置換し、コード生成部１１５によって、オーバロードタグ関数に置換された新規アプリソースファイル１３１と、オーバロードタグ関数インクルードファイル１３４およびオーバロードタグ関数ソースファイル１３５から新規アプリのデバッグ用実行形式ファイル１３２を生成し、新規アプリ３１７のデバッグ用実行形式ファイル１３２を実行しているので、コントロールサービス関数や標準関数のソースコードが公開されていない場合でも、メモリアクセスによるメモリ状態遷移を検証することができ、正確なデバッグ作業を行うことができる。
【０１０８】
また、実施の形態１にかかるデバッグ装置１００およびデバッグ用アプリケーション生成プログラムでは、オーバロードタグ関数を利用してメモリアクセス検証を行っているので、デバッグ作業に必要な関数だけをオーバロードタグ関数に置換すれば良く、このため、新規アプリ３１７の中で一部の箇所または特定の関数についてだけのメモリアクセスの検証を行うことができ、デバッグ作業を効率的に行うことができる。
【０１０９】
また、このように特定の関数だけをオーバロードタグ関数に置換することでメモリアクセスの検証を行えるので、関数外部へのメモリアクセスや関数内部におけるメモリアクセスを区別したり、ＣＰＵまたはコンパイラに依存する箇所と非依存の箇所とを区別してメモリアクセスの検証を行うことができ、デバッグ作業をより効率的に行うことができる。
【０１１０】
なお、実施の形態１で説明した各ファイルの内容は一例を示すものであり、その内容について特に限定されるものではない。
【０１１１】
（実施の形態２）
実施の形態１のデバッグ装置１００およびデバッグ用アプリケーション生成プログラムは、オーバロードタグ関数インクルードファイル１３４およびオーバロードタグ関数ソースファイル１３５を事前にユーザによって作成してから検証を行っていたが、この実施の形態２にかかるデバッグ装置１１００およびデバッグ用アプリケーション生成プログラムは、新規アプリのソースファイルのコンパイル時にオーバロードタグ関数インクルードファイル１３４およびオーバロードタグ関数ソースファイル１３５を自動的に生成してデバッグ用新規アプリの実行形式ファイルを生成するものである。
【０１１２】
図１１は、実施の形態２にかかるデバッグ装置１１００のソフトウェア構成を示すブロック図である。実施の形態２にかかるデバッグ装置１１００は、図１１に示すように、デバッグ機能付きコンパイラ１１１０と、リンカ１２０とから構成される。
【０１１３】
デバッグ機能付きコンパイラ１１１０は、ハードディスク（ＨＤ）１３０に格納されたアプリケーションのソースコードが記述されたソースファイル１３１を、コマンドの指定に従って、タグやオーバロードタグ関数処理を行って、アプリケーションのオブジェクトコードからなるオブジェクトファイルを生成するものである。デバッグ機能付きコンパイラ１１１０は、図１１に示すように、さらにコマンド解析部１１１と、構文解析部１１２と、オーバロードタグ関数コード生成部１１１１と、オーバロードタグ関数処理部１１３と、タグ付加部１１４と、コード生成部１１５とから構成される。
【０１１４】
実施の形態２のデバッグ機能付きコンパイラ１１１０は、オーバロードタグ関数コード生成部１１１１を備えている点が、実施の形態１におけるデバッグ機能付きコンパイラ１１０と異なり、この他の構成は実施の形態１のデバッグ機能付きコンパイラ１１０と同様である。
【０１１５】
オーバロードタグ関数コード生成部１１１１は、ユーザが設定したオーバロードタグ関数設定ファイル１３３に指定された関数に対応したオーバロードタグ関数を生成し、生成された各オーバロードタグ関数の宣言を記述したオーバロードタグ関数インクルードファイル１３４と、各オーバロードタグ関数の処理を記述したオーバロードタグ関数ソースファイル１３５をＨＤ１３０に生成するものである。
【０１１６】
ＨＤ（ハードディスク）１３０には、実施の形態１にかかるデバッグ装置１００と同様に、ソースファイル１３１と、オーバロードタグ関数設定ファイル１３３とが格納されている。実施の形態２にかかるデバッグ装置１１００では、デバッグ用新規アプリ３１７の生成処理中にデバッグ用実行形式ファイル１３２と中間ソースファイル１３８とオブジェクトファイル１３９がＨＤ１３０に生成される他、実施の形態１のデバッグ装置１００と異なり、オーバロードタグ関数インクルードファイル１３４とオーバロードタグ関数ソースファイル１３５もデバッグ機能付きコンパイラ１１１０によって生成される。なお、各ファイルの構造および内容については、実施の形態１で説明した各ファイル構造および内容と同様である。
【０１１７】
次に、以上のように構成された実施の形態２にかかるデバッグ装置１１００およびデバッグ用アプリケーション生成プログラムによるデバッグ用新規アプリ３１７の生成およびメモリアクセス検証方法について説明する。コマンド解析部１１１によるコマンド解析処理、構文解析部１１２によるソースファイル１３１の構文解析処理、リンカ１２０によるオブジェクトファイル１３９と各ライブラリとのリンク処理については、図７に示す実施の形態１のデバッグ装置１００およびデバッグ用アプリケーション生成プログラムにおける処理手順と同様である。
【０１１８】
図１２は、オーバロードタグ関数コード生成処理、オーバロードタグ関数処理およびコード生成処理の手順を示すフローチャートである。まず、オーバロードタグ関数処理部１１３によって、環境変数ＯＶＲ＿ＸＭＬに設定されたオーバロードタグ関数設定ファイル１３３（ｎｅｗａｐｐｌ．ｘｍｌ）を読み込む（ステップＳ１２０１）。そして、オーバロードタグ関数処理部１１３は、オーバロードタグ関数設定ファイル１３３（ｎｅｗａｐｐｌ．ｘｍｌ）の＜ｆｕｎｃ＞タグを参照し、オーバロードタグ関数に置換する関数を全てリストアップする（ステップＳ１２０２）。
【０１１９】
次に、オーバロードタグ関数コード生成部１１１１によって、リストアップされた関数名に対応するオーバロードタグ関数名を決定し、各オーバロードタグ関数の宣言を記述したオーバロードタグ関数インクルードファイル１３４とオーバロードタグ関数ソースファイル１３５を生成し、オーバロードタグ関数設定ファイル１３３で指定されたディレクトリパスに、同ファイル１３３に指定された各ファイル名で格納する（ステップＳ１２０３）。
【０１２０】
ここで、オーバロードタグ関数コード生成部１１１１によるオーバロードタグ関数ソースファイル１３５の生成処理について説明する。実施の形態１で説明した通り、オーバロードタグ関数は、置換元の関数のメモリに対するアクセスの方法によって、メモリ状態イベント関数を適宜選択してメモリアクセスによる状態遷移を検証している。すなわち、関数の処理の中で、引数ポインタが指すメモリ領域に対し読み込みアクセスを行っている場合には、関数実行後にｅｖｅｎｔ＿ｒｅａｄのイベント関数によってメモリの遷移状態をチェックし、引数ポインタが指すメモリ領域に対し書き込みアクセスを行っている場合には、関数実行後にｅｖｅｎｔ＿ｗｒｉｔｅのイベント関数によってメモリの遷移状態をチェックしている。従って、実施の形態２のデバッグ装置１１００では、あらかじめオーバロードタグ関数のへの置換対象となり得る関数に対して、その引数が指す領域に対するアクセス方法を関数テーブルで保持している。
【０１２１】
図１３は、かかる関数テーブルの一例を示す説明図である。図１３は、図５に示したオーバロードタグ関数の置換元の関数ｅｃｓ＿ｊｏｂｍｏｄｅ，ｅｃｓ＿ｍｓｇａｌｌｏｃ，ｓｔｒｃｐｙのそれぞれについて、各引数ポインタの指すメモリ領域に対するアクセス方法を記録している。オーバロードタグ関数コード生成部１１１１は、関数の引数ごとにかかる関数テーブルを参照して、読み込みアクセス、書き込みアクセス、確保アクセス、開放アクセスを判断し、メモリ状態イベント関数ｅｖｅｎｔ＿ｒｅａｄ、ｅｖｅｎｔ＿ｗｒｉｔｅ、ｅｖｅｎｔ＿ａｌｌｏｃ、ｅｖｅｎｔ＿ｆｒｅｅの中から選択してオーバロードタグ関数ソースファイル１３５を生成する。また、オーバロードタグ関数コード生成部１１１１は、生成したオーバロードタグ関数の宣言を記述してオーバロードタグ関数インクルードファイル１３４を生成する。
【０１２２】
図１２のステップＳ１２０３によって、オーバロードタグ関数インクルードファイル１３４とオーバロードタグ関数ソースファイル１３５が生成されたら、ＨＤ１３０に中間ソースファイル１３８を生成し、ソースファイル１３１（ｎｅｗａｐｐｌ．ｃ）の内容を中間ソースファイル１３８にコピーする（ステップＳ１２０４）。これ以降の、オーバロードタグ関数処理部１１３による対象関数のオーバロードタグ関数への置換、コード生成部１１５によりオブジェクトコードへの変換およびオブジェクトファイル１３９の生成処理の手順（ステップＳ１２０５〜Ｓ１２０９）は、実施の形態１のデバッグ装置１００およびデバッグ用アプリケーション生成プログラムによる図８で説明した手順（ステップＳ８０４〜Ｓ８０８）と同様に行われる。そして、生成されたオブジェクトファイル１３９をリンカ１２０によってＥＣＳ関数ライブラリ１３６（ｅｃｓ．ｌｉｂ）と標準関数ライブラリ１３７（ｓｔａｎｄａｒｄ．ｌｉｂ）とリンクすることにより、デバッグ用新規アプリ３１７の実行形式ファイル１３２（ｎｅｗａｐｐｌ．ｅｘｅ）が生成される。
【０１２３】
このように実施の形態２にかかるデバッグ装置１１００およびデバッグ用アプリケーション生成プログラムでは、オーバロードタグ関数コード生成部１１１１によって、コントロールサービス関数および標準関数に対するオーバロードタグ関数のオーバロードタグ関数ソースファイル１３５およびオーバロードタグ関数インクルードファイル１３４を自動的に生成しているので、オーバロードタグ関数ソースファイル１３５およびオーバロードタグ関数インクルードファイル１３４をデバッグ作業者自ら作成する必要がなく、正確なデバッグ作業を効率的に行うことができる。
【０１２４】
なお、実施の形態１および２にかかるデバッグ装置１１００およびデバッグ用アプリケーション生成プログラムでは、新規アプリを生成する場合について説明しているが、この他コントロールサービスの生成について本発明を適用することも可能である。
【０１２５】
【発明の効果】
以上説明したように、請求項１にかかる発明によれば、サービス関数のソースコードが公開されていない場合でも、サービス関数の機能を把握していれば、アプリケーションの実行時にサービス検証関数によってメモリアクセスによるメモリ状態を検証することができ、一部のソースコードが不明な場合でも正確なデバッグ作業を行うことができるという効果を奏する。また、請求項１にかかる発明によれば、メモリ確保アクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができるという効果を奏する。
【０１２６】
また、請求項２にかかる発明によれば、一部の関数のみにおけるメモリアクセスの検証を行うことができ、デバッグ作業を効率的に行うことができるという効果を奏する。
【０１２８】
また、請求項３にかかる発明によれば、メモリ書き込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができるという効果を奏する。
【０１２９】
また、請求項４にかかる発明によれば、メモリ読み込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができるという効果を奏する。
【０１３０】
また、請求項５にかかる発明によれば、メモリ開放アクセスによる障害を正確に検知することができ、より正確なデバッグ作業を行うことができるという効果を奏する。
【０１３１】
また、請求項６にかかる発明によれば、サービス関数だけでなく、ソースコードが公開されない標準関数からメモリアクセスを行う場合でも、標準関数の機能を把握していれば、アプリケーションの実行時に標準検証関数によってメモリアクセスによるメモリ状態を検証することができ、標準関数のライブラリのみが提供されている場合でも正確なデバッグ作業を行うことができるという効果を奏する。
【０１３２】
また、請求項７にかかる発明によれば、サービス関数のソースコードが公開されていない場合でも、サービス検証関数ソースファイルをデバッグ作業者自ら作成することなく、正確なデバッグ作業を効率的に行うことができるという効果を奏する。
【０１３４】
また、請求項８にかかる発明によれば、アプリケーションの実行時に、ソースファイルが自動生成されたメモリ書き込みアクセスを検証するサービス検証関数によってメモリ書き込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を効率的に行うことができるという効果を奏する。
【０１３５】
また、請求項９にかかる発明によれば、アプリケーションの実行時に、ソースファイルが自動生成されたメモリ読み込みアクセスを検証するサービス検証関数によってメモリ読み込みアクセスによる障害を正確に検知することができ、より正確なデバッグ作業を効率的に行うことができるという効果を奏する。
【０１３６】
また、請求項１０にかかる発明によれば、アプリケーションの実行時に、ソースファイルが自動生成されたメモリ開放アクセスを検証するサービス検証関数によってメモリ開放アクセスによる障害を正確に検知することができ、より正確なデバッグ作業を効率的に行うことができるという効果を奏する。
【０１３８】
また、請求項１１にかかる発明によれば、請求項１〜１０のいずれか一つの動作をコンピュータによって実行することができるという効果を奏する。
【図面の簡単な説明】
【図１】実施の形態１にかかるデバッグ装置の機能的構成を示すブロック図である。
【図２】実施の形態１にかかるデバッグ装置のハードウェア構成を示すブロック図である。
【図３】実施の形態１にかかる複合機の機能的構成を示すブロック図である。
【図４】実施の形態１にかかる複合機の新規アプリとコントロールサービスの関数呼び出しの関係を示すブロック図である。
【図５】実施の形態１にかかるデバッグ装置におけるデバッグ用新規アプリの生成処理において、使用および生成されるファイルと、デバッグ用新規アプリの全体の流れを示した説明図である。
【図６】実施の形態１にかかるデバッグ装置において、図５におけるオーバロードタグ関数設定ファイルの内容の一例を示す説明図である。
【図７】実施の形態１にかかるデバッグ装置におけるデバッグ用新規アプリの生成処理の手順を示すフローチャートである。
【図８】実施の形態１にかかるデバッグ装置におけるオーバロードタグ関数処理およびコード生成処理の手順を示すフローチャートである。
【図９】実施の形態１にかかるデバッグ装置におけるオーバロードタグ関数ソースファイルの詳細の一例を示す説明図である。
【図１０】実施の形態１にかかる複合機におけるメモリの状態遷移とメモリアクセスの関係を示す説明図である。
【図１１】実施の形態２にかかるデバッグ装置の機能的構成を示すブロック図である。
【図１２】実施の形態２にかかるデバッグ装置におけるオーバロードタグ関数コード生成処理、オーバロードタグ関数処理およびコード生成処理の手順を示すフローチャートである。
【図１３】実施の形態２にかかるデバッグ装置で使用する関数テーブルの一例を示す説明図である。
【符号の説明】
１００，１１００  デバッグ装置
１１０，１１１０  コンパイラ
１１１  コマンド解析部
１１２  構文解析部
１１３  オーバロードタグ関数処理部
１１４  タグ付加部
１１５  コード生成部
１２０  リンカ
１３０  ハードディスク（ＨＤ）
１３１  新規アプリソースファイル
１３２  デバッグ用実行形式ファイル
１３３  オーバロードタグ関数設定ファイル
１３４  オーバロードタグ関数インクルードファイル
１３５  オーバロードタグ関数ソースファイル
１３６  コントロールサービス関数ライブラリ
１３７  標準関数ライブラリ
１３８  中間ソースファイル
１３９  オブジェクトファイル
２０１  入力装置
２０２  表示装置
２０３  制御装置
２０４  通信装置
２０５  ＲＡＭ
３００  複合機
３０１  白黒ラインプリンタ
３０２  カラーラインプリンタ
３０３  ハードウェアリソース
３１０  ソフトウェア群
３１１  プリンタアプリ
３１２  コピーアプリ
３１３  ファックスアプリ
３１４  スキャナアプリ
３１５  ネットファイルアプリ
３１６  工程検査アプリ
３１７  新規アプリ
３２０  プラットホーム
３２１  汎用ＯＳ
３２２  ＳＣＳ
３２３  ＳＲＭ
３２４  ＥＣＳ
３２５  ＭＣＳ
３２６  ＯＣＳ
３２７  ＦＣＳ
３２８  ＮＣＳ
３３０  アプリケーション
１１１１  オーバロードタグ関数コード生成部
【図１】
0004080739.tif 000002
【図２】
0004080739.tif 000003
【図３】
0004080739.tif 000004
【図４】
0004080739.tif 000005
【図５】
0004080739.tif 000006
【図６】
0004080739.tif 000007
【図７】
0004080739.tif 000008
【図８】
0004080739.tif 000009
【図９】
0004080739.tif 000010
【図１０】
0004080739.tif 000011
【図１１】
0004080739.tif 000012
【図１２】
0004080739.tif 000013
【図１３】
0004080739.tif 000014