JP2009098907A

JP2009098907A - デバッグ装置及びデバッグ方法

Info

Publication number: JP2009098907A
Application number: JP2007269523A
Authority: JP
Inventors: Akira Sawaoka; 明澤岡
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2007-10-16
Filing date: 2007-10-16
Publication date: 2009-05-07

Abstract

【課題】プログラムの開発時に、デッドロックの発生あるいは優先度逆転現象の発生を検出することができるデバッグ装置を提供する。
【解決手段】デバッグ装置１は、プログラム１５の実行中にOS１６において発生するイベントに応じて生成されるログ情報を解析して、プログラムの各タスクの状態と各タスクが使用する資源の使用状態を検出する。そして、デバッグ装置１は、解析して得られた各タスクの状態の情報（TIT）と各タスクが使用する資源の使用状態の情報（RIT）を記憶する。デバッグ装置１は、ログ情報の入力に応じて、各タスクの状態と各タスクが使用する資源の使用状態の情報に基づいて、タスク間でのデッドロック状態またはタスク間での優先度逆転状態の発生を検出し、その発生したことを示す発生情報を出力する。
【選択図】図１

Description

本発明は、デバッグ装置及びデバッグ方法に関する。

近年、コンピュータを利用した情報処理技術の一つに、複数のタスクあるいは複数のプロセスを同時に実行するマルチタスクシステムがある。マルチタスクあるいはマルチプロセスのシステムでは、資源の共有が行われるため、いわゆるデッドロックの問題がある。アプリケーションのソフトウエアプログラム（以下、単にプログラムともいう）の実行中にいわゆるデッドロック、言い換えるとすくみ状態、が発生すると、そのプログラム中の複数のタスクは互いに実行できない状態になってしまう。そのため、デッドロックが発生した場合には、プログラムの実行が継続して行われるように、通常は、所定の対策処理が実行される。

従来より、このようなデッドロックの発生に関する種々の技術が提案されている。例えば、プログラムの実行中におけるデッドロックを検出する技術、プログラムの実行中におけるデッドロックを防止する技術、及びプログラムの実行中にデッドロックを検出してデッドロックの状態から回復する技術が、種々提案されている（例えば、特許文献１、２、３参照）。

しかし、これらの技術は、プログラムの実行中にデッドロックが発生しても、プログラムの実行が継続するようにするために、デッドロックの検出、防止等を行うための技術である。言い換えると、これらの提案に係る技術は、プログラムの実行中にデッドロックを検出して、自動的にプログラムの実行を継続させるための技術である。自動的にプログラムの実行を継続する場合、デッドロックの検出タイミングにおいて、他タスク、ハンドラ、あるいはそれ以降の処理を考慮せずに、対策処理すなわち回復処理が実行される。

ところで、従来、プログラムの開発中にデッドロックの発生自体を検出する技術はなかった。プログラムの開発においては、プログラム開発者は、プログラムのデバッグ時にプログラム実行中に何らかの動作異常があると、その異常の原因がデッドロックの発生であったことを、プログラムの実行過程をトレースすることによって、発見していた。その場合、デッドロックの発生原因を突き止めるためには、プログラム開発者は、一般的に利用することができる開発ツールなどのデバッグ機能を使い、プログラムの実行過程等のトレースを行う。そのトレースを行うことによって、プログラムの動作の確認をすることができ、その結果として、デッドロックの発生を見出すことができる。なお、その場合、ユーザには、これらのツール及び環境に依存する制限、その制限を確認する知識及び技術が必要とされ、そのような知識等を利用して、デッドロックの発見をすることができる。

また、開発中のプログラムを実行した結果においては処理の目的は達成しているが、その処理の過程において、あるタスク間でのデッドロックの発生、あるいは設計時に意図していない優先度逆転の状態の発生をしている可能性もある。

しかし、デバッグ時にデッドロックが発生しても、上述したように、自動的にプログラムの実行を継続させる対策処理が実行されるので、ユーザは、デッドロック状態、あるいはタスク間における優先度逆転現象の状態を検出したくても、処理中における異常がない限り、デッドロック状態自体、あるいは優先度逆転現象自体を検出することができず、さらにデッドロックの発生原因を追及するための情報を得ることも出来なかった。

また、優先度逆転現象の場合、開発者がその優先度の逆転を意図して発生させている場合もあり、優先度逆転現象の発生に対して自動的に対策処理を行わなくてもよい場合もある。ユーザの意図していた優先度逆転現象に対してまでも、そのような対策処理を行うことはオーバヘッドの発生となってしまう。
以上のように、ユーザは、プログラムの開発時に、デッドロックの発生あるいは優先度逆転現象の発生を検出することはできなかった。
特開2001-259433号公報特開平9-3302415号公報特開2004-341878号公報

そこで、本発明は、プログラムの開発時に、デッドロックの発生あるいは優先度逆転現象の発生を検出することができるデバッグ装置及びその方法を提供することを目的とする。

本発明の一態様によれば、プログラムの実行中にオペレーティングシステムにおいて発生するイベントに応じて生成されるログ情報を解析して、前記プログラムの各タスクの状態と前記各タスクが使用する資源の使用状態を検出するログ情報解析部と、該ログ情報解析部によって解析して得られた前記各タスクの状態の情報と前記各タスクが使用する資源の使用状態の情報を記憶する状態情報記憶部と、前記ログ情報の入力に応じて、前記各タスクの状態と前記各タスクが使用する資源の使用状態の情報に基づいて、タスク間でのデッドロック状態またはタスク間での優先度逆転状態の発生を検出するタスク状態検出部と、該タスク状態検出部によって検出された前記タスク間でのデッドロック状態または前記タスク間での優先度逆転状態が発生したことを示す発生情報を出力する発生情報出力部と、を有することを特徴とするデバッグ装置を提供することができる。

本発明の一態様によれば、プログラムの実行中にオペレーティングシステムにおいて発生するイベントに応じて生成されるログ情報を解析して、前記プログラムの各タスクの状態と前記各タスクが使用する資源の使用状態を検出し、解析して得られた前記各タスクの状態の情報と前記各タスクが使用する資源の使用状態の情報を記憶し、前記ログ情報の入力に応じて、前記各タスクの状態と前記各タスクが使用する資源の使用状態の情報に基づいて、タスク間でのデッドロック状態またはタスク間での優先度逆転状態の発生を検出し、検出された前記タスク間でのデッドロック状態または前記タスク間での優先度逆転状態が発生したことを示す発生情報を出力することを特徴とするデバッグ方法を提供することができる。

本発明によれば、プログラムの開発時に、デッドロックの発生あるいは優先度逆転現象の発生を検出することができる。

以下、図面を参照して本発明の実施の形態を説明する。
（第１の実施の形態）
まず図１に基づき、本発明の第１の実施の形態に係わるプログラム開発システムの構成を説明する。

（装置構成）
図１は、本実施の形態に係わるプログラム開発システムの構成を示す構成図である。
開発装置としてのプログラム開発システム１は、デバッグ装置であるホスト側のコンピュータ（以下、ホストコンピュータという）２と、ターゲットボード３と、モニタ等の出力装置４とを含んで構成されている。
ホストコンピュータ２は、パーソナルコンピュータ等であり、プログラムを開発するために一般的に使用されているソフトウエアプログラムであるプログラム開発ツール１１と、ワーニング事象通知部１２と、解析情報を記憶するデータ記憶部１３とを含むデバッグ装置である。ユーザは、プログラム開発ツール１１を利用して、開発対象であるアプリケーションプログラム１５の作成、そのプログラム１５のデバッグ、ターゲットボード３におけるプログラム１５の実行制御、等のための操作を行うことができる。プログラム１５は、例えば、リアルタイムOSなどのマルチタスク制御システム上で実行させるアプリケーションプログラムである。

ターゲットボード３は、開発対象であるアプリケーションプログラム（以下、単にプログラムという）１５と、そのプログラム１５を搭載し実行を制御するオペレーティングシステム（以下、OSという）１６と、ログ出力部１７とを含む。OS１６は、後述するログデータを生成するログ生成部１８を含む。
ターゲットボード３は、例えば、開発対象のプログラム１５を実行する１チップの半導体装置であるプロセッサを基板上に搭載した配線板、あるいは基板上で各種回路素子を配線により接続して模擬的に実現した配線板である。従って、ターゲットボード３にはOS１６も搭載可能であり、ユーザは、そのOS１６上で、開発中の、あるいは開発した、プログラム１５を実行させることができる。

ホストコンピュータ２とターゲットボード３は、ケーブル１９により接続され、互いにコマンド及びデータの送受信が可能となっている。ホストコンピュータ２からのプログラムの実行命令等が、コネクタケーブルを介して、ターゲットボード３に供給される。

さらに、ログ生成部１８は、通常のOSが有する、ログデータを生成するソフトウエアプログラムである。ログ生成部１８のログ出力機能は、一般的な手段によるもので、ログ情報の生成を行うときは、実行中のソフトウエアプログラムの実行を一時的に中断し、一つあるいは複数のログ情報を、逐次生成して出力する仕組みを備えている。その一時的な中断の処理は、通常のOS１６が備えているログ出力機能における中断処理と同じであり、ソフトウエアプログラムへの影響を極めて最小限に抑えられるように設計されている。このようなログ出力機能を使うことで、OS１６において発生するイベントの情報がリアルタイムに利用することができる。

具体的には、ログ生成部１８は、プログラム１５から実行要求されたコマンド、コマンドに応じて実行した内容、プログラム１５の実行中に発生した事象、等をログ情報として生成する関数である。ログ生成部１８は、プログラム１５の実行中にOS１６において発生したイベントの情報を逐次生成して、ログ情報LDとして、ログ出力部１７に出力する。よって、ログ出力部１７は、ケーブル１９を介してワーニング事象通知部１２にログ情報LDを出力する。

ホストコンピュータ２は、上述したように、ワーニング事象通知部１２を備える。ワーニング事象通知部１２は、ログ出力部１７から出力されるログ情報LDを受信して解析し、データ記憶部１３に対して、解析して得られた情報の構築、追加、修正、削除などの管理を行うプログラムである。後述するように、ワーニング事象通知部１２は、そのデータ記憶部１３に記憶された情報から、ワーニング事象としてのデッドロック状態を検出して出力装置４へその検出した事象の報告すなわち出力する機能も有する。また、ワーニング事象通知部１２は、OS１６において発生しているイベントの情報から、プログラム開発ツール１１へ、イベント情報EDの報告すなわち出力する機能も有する。

また、データ記憶部１３には、後述するタスク情報管理テーブルを記憶するタスク情報記憶部１３ａと、後述する資源情報管理テーブルを記憶する資源情報記憶部１３ｂとを含む。

（各処理部の動作あるいは機能）
次に、各処理部の動作あるいは機能について説明する。
（OS）
OS１６は、一般的なマルチタスク制御を提供するOSであり、タスクあるいはプロセスの単位に分割される複数のプログラムの実行を制御する。OS１６は、アプリケーションプログラムを構成するタスク、ハンドラ、タスク及びハンドラから利用されるセマフォ及びメモリの共有資源（以下、タスク、ハンドラ、共有資源を纏めて指す場合はオブジェクトと記す）の管理機能を有する。OS１６は、さらに、これらオブジェクトを操作するインターフェース（以下、このインターフェースをサービスコールという）を有する。さらに、OS１６は、OS内部においてイベントが発生した場合に、ログ情報LDをログ生成部１８から出力する。

タスク、セマフォ、メモリ等の各オブジェクトは、ユーザにより予め設定された、オブジェクト種別に応じて特定の識別子（以下、IDという）を有し、さらに、各タスクには優先度の情報も設定されている。OS１６は、実行するタスクを優先度に従って決定するタスクスケジューリング機能と、実行タスクを切り替えるディスパッチ機能とを有する。

（タスクの状態）
図２は、本実施の形態に係るタスクの状態遷移図である。各タスクは、タスクスケジューリング機能に従って、４つの状態を取り得る。４つの状態は、ここでは、実行状態（S-1）、実行可能状態（S-2）、待ち状態（S-3）及び休止状態（S-4）である。タスクスケジューリング機能により、一つのタスクが実行状態(S-1)になると、他のタスクは、実行状態ではないタスクとされる。実行状態(S-1)以外の状態は複数あり、各状態に対して複数のタスクが存在可能である。タスクは各状態間を遷移する。例えば、実行状態(S-1)のタスクが処理を終了あるいは中断する時は、利用したサービスコールの機能により、実行可能状態(S-2)、待ち状態(S-3)及び休止状態(S-4)のいずれか一つに遷移し、次に、タスクスケジューリング機能により、実行可能状態(S-2)のタスクの中で、一番優先度の高いタスクが実行状態(S-1)に遷移し、同時にディスパッチ処理が発生される。

（ログ情報）
OS１６において発生するイベントの中で、本実施の形態において必要なイベントの種類としては、OS１６が提供するサービスコールの利用と、そのサービスコールの利用に起因して発生するタスクのディスパッチとがある。ログ生成部１８は、OS１６の管理する情報を参照し、図３に示すようなデータを生成して、出力する。

図３は、ログ生成部１８が生成して出力するログ情報LDのデータフォーマットの構成を示す図である。ログ情報LDのデータフォーマットは、複数のデータフィールド部からなり、具体的には、ログコード２１、サブコード２２、ターゲットID２３、タスクID２４、拡張情報２５、及びプログラムカウンタ２６の６つのデータフィールド部を有している。

ログコード２１は、OS１６内で発生したイベント等のコード情報である。
サブコード２２は、ログコード部２１に関連するコード情報である。
ターゲットID２３は、OS１６の管理する、例えばセマフォ、メモリ等のリソースのID情報である。
タスクID２４は、アプリケーションプログラム１５のタスクのID情報、すなわちタスク識別情報である。
拡張情報２５は、例えば、タスクに関する補足情報等の付加情報である。
プログラムカウンタ２６は、イベントが発生した時のプログラムカウンタの値である。

図４及び図５は、ログ情報LDの例を示す図である。図４は、サービスコール利用時におけるログ情報LDの例を示す図である。図５は、タスクのディスパッチ時におけるログ情報LDの例を示す図である。

図４に示すように、サービスコールが利用されると、そのログ情報LDが生成され、ログ情報LD中、ログコード２１にサービスコール識別コード、サブコード２２にエラーコード、ターゲットID、タスクIDにサービスコール発行タスクID、拡張情報２５にタスク操作時の引数情報、及びプログラムカウンタ２６にサービスコール発行時のプログラムカウンタのアドレスが含まれる。なお、エラーコードは、サービスコールの発行が成功したか否かを示す情報である。

また、図５に示すように、タスクのディスパッチが発生すると、そのログ情報LDが生成され、ログ情報LD中、ログコード２１にディスパッチコード、サブコード２２に０、ターゲットIDにディスパッチ後のタスクID、タスクIDにディスパッチ前のタスクID、拡張情報２５に０、及びプログラムカウンタ２６に０が含まれる。なお、ディスパッチ後のタスクIDは、ディスパッチによりその後に実行されるタスクのIDであり、ディスパッチ前のタスクIDは、ディスパッチ前に実行されていて、ディスパッチ後は実行されなくなるタスクのIDである。

以上説明したログ情報LDは、ログ生成部１８において生成され、ログ出力部１７を介してワーニング事象通知部１２へ供給される。

ホストコンピュータ２のワーニング事象通知部１２は、供給されたログ情報LDから、解析情報としてのオブジェクト情報管理情報を生成し、さらに、検出したイベント情報EDをプログラム開発ツール１１及び出力装置４へ出力する。プログラム開発ツール１１は、イベント情報EDを受信した場合、例えば、ターゲットボード３上で実行中のプログラム１５の実行を停止するといった動作をするように、設定あるいは制御を行うことができる。

（オブジェクト情報管理情報）
図６及び図７は、解析情報としてのオブジェクト情報管理情報の例を示す図である。ワーニング事象通知部１２は、ログ情報LDを受信すると、オブジェクト情報管理情報の生成あるいは更新を行う。オブジェクト情報管理情報は、初期値が予め設定されており、プログラム１５の実行後は、ログ情報LDに基づいて動的に更新されていく。

図６は、オブジェクト情報管理情報の一つであるタスク情報管理データTIのデータフォーマットの構成を示す図である。タスク情報管理データTIのデータフォーマットは、複数のデータフィールド部からなり、具体的には、タスクID３１、タスクの優先度３２、タスクの状態３３、セマフォ３４、及びメモリ３５についての５つのデータフィールド部を有している。タスクID３１は、タスクを識別するためのタスク識別情報である。タスクの状態３３は、タスクの状態を示す状態情報である。セマフォ３４とメモリ３５は、各資源の獲得及び空き待ちの状態を示す資源獲得状態情報である。

タスクID３１により特定されるタスク毎に、その優先度３２、タスクの状態３３、セマフォ３４及びメモリ４５についての内容が記憶される。ワーニング事象通知部１２では、ログ情報LDを受信すると、図３のタスクID２４の情報に基づいて、対応するタスクID３１の有無がチェックされる。ワーニング事象通知部１２は、タスクID２４に対応するタスクID３１について、拡張情報２５に含まれる引数情報２５からタスクの優先度３２を抽出し、サービスコール利用時あるいはディスパッチ発生時にログ情報LDからタスクの状態３３を抽出し、サービスコール利用時のログコード２１とターゲットID２３からセマフォ３４とメモリ３５のID情報を抽出する。

図７は、オブジェクト情報管理情報の一つである資源情報管理データRIのデータフォーマットの構成を示す図である。資源情報管理データRIのデータフォーマットは、複数のデータフィールド部からなり、具体的には、資源ID４１、資源を獲得したタスクID４２、及び資源を獲得したときの位置、すなわちプログラムカウンタのアドレス４３を有している。

ターゲットID２３により特定される資源ID４１毎に、資源を獲得したタスクID４２、及び資源を獲得したときの位置４３の内容が記憶される。ワーニング事象通知部１２では、ログ情報LDを受信すると、図３のターゲットID２３の情報に基づいて、ターゲットID２３に対応する資源ID４１について、サービスコール発行タスクID２４から資源を獲得したタスクID４２を抽出し、サービスコール発行アドレス２６から資源を獲得した位置４３の情報を抽出する。

これらのオブジェクト情報管理情報は、タスクID及び資源ID毎に生成される。タスクID毎に生成された複数のタスク情報管理データTIはテーブル形式のテーブルデータとして、データ記憶部１３のタスク情報記憶部１３ａに記憶され、資源ID毎に生成された複数の資源情報管理データRIはテーブル形式のテーブルデータとして、データ記憶部１３の資源情報記憶部１３ｂに記憶される。以下、タスク情報管理データTIのデータテーブルを、タスク情報管理テーブルTITといい、資源情報管理データRIのデータテーブルを、資源情報管理テーブルRITという。すなわち、タスク情報記憶部１３ａは、タスク情報管理テーブルを有し、資源情報記憶部１３ｂは、資源情報管理テーブルを有する。よって、データ記憶部１３は、各タスクの状態の情報と、各タスクが使用する資源の使用状態の情報を記憶する状態情報記憶部を構成する。

タスク情報管理テーブルTITは、アプリケーションプログラム１５において生成あるいは開始されるタスクの数の分だけレコードを含み、各タスクの管理情報と各タスクの資源取得状況を管理するためのテーブルである。また、資源情報管理テーブルRITは、オブジェクト種別毎のテーブルが作成され、資源が取得されている状況を管理するためのテーブルである。以下、この２種類のテーブルを纏めて指す場合は、オブジェクト情報管理テーブルOITという。

タスク情報管理テーブルTITにおいては、タスクを生成あるいは開始するサービスコールの利用があった場合に、新規のレコードが追加され、資源を操作するサービスコールの利用があった場合は、対象タスクのレコードの情報が更新される。資源情報管理テーブルRITにおいては、管理するオブジェクトを生成するタイミング、あるいは初めて使用するタイミングにおいてテーブルが作成され、資源の取得と返却に応じて、各資源のレコードの追加と削除の操作が行われる。

（ワーニング事象通知部の動作）
次に、上述した構成のワーニング事象通知部１２における動作を、３つのタスクが動作する場合を例として、説明する。
図８は、タスクと資源の状態の変化を説明するための図である。図８は、デッドロックが発生するまでの経過を示している。タスクAはIDが1で、タスクBはIDが2で、タスクCはIDが３である。以下、IDが1をID1と、IDが２をID2と、IDが３をID3という。

図８の例では、３つのタスクA，B，Cを含む、タスク及びハンドラにより構成されるアプリケーションプログラムにおいて、タスクAの優先度は３で、タスクBの優先度は５で、タスクCの優先度は７で、３つのタスクにおける優先度は以下の関係にある。
タスクA＞タスクB＞タスクC
さらに、セマフォ資源の内、ID１のセマフォ資源は、２つのタスクが使用でき、メモリ資源の内、ID1のメモリ資源は、１つしか使用できないものとする。
図８は、この条件において、タスクAとBの間で発生するデッドロックの検出と、デッドロックの発生を通知する例を示す。

図８は、一般的なOSを利用するアプリケーションにおいて、デッドロックの発生に対する対策処理がユーザあるいはOSによって行われていない場合における、デッドロックの事象が発生するまでの経過の例を示し、時刻t7において、ID1のメモリ資源を、タスクAが獲得しようとした結果、タスクAとタスクBの間でデッドロックが発生していることを示している。デッドロックが発生していることについては、後で詳述する。

また、図９は、図８の場合におけるタスク情報管理テーブルTITと、セマフォとメモリの各資源情報管理テーブルRITの状態を説明するための図である。

図８に示すように、タスクAは、待ち状態、具体的にはID1のメモリ資源が空くのを待っている状態から、時刻t6において実行状態に遷移し、その後時刻t8において待ち状態に遷移している。タスクBは、実行状態から、時刻t3において、待ち状態に遷移している。さらに、タスクCは、実行可能状態から、時刻t3において、実行状態に遷移し、その後時刻t6において実行可能状態に遷移し、さらに時刻t8において実行状態に遷移している。

具体的に、各タスクの資源の獲得について説明する。タスクCがID1のセマフォ資源を既に獲得しており、タスクBは、時刻t1においてID1のセマフォ資源を獲得している。さらにタスクBは、さらに時刻t2において、ID１のメモリ資源を獲得しようとするが、ID1のメモリ資源は既にタスクCによって使用されているため、獲得できず、その結果、時刻t3において、タスクBは実行状態から待ち状態に遷移する。

タスクCは、時刻t3において実行状態になり時刻t4において、ID1のメモリ資源を返却し、ID１のメモリ資源は、使用可能状態となる。図８では、時刻t4から、ID1のメモリ資源の残り資源は１になっている。

その結果、ID１のメモリ資源の空きを待っている、タスクB、Cよりも優先度の高いタスクAが、待ち状態から実行状態に遷移し、時刻t6において、ID1のメモリ資源を獲得している。

タスクAが実行中に、ID1のセマフォ資源を獲得しようとするが、ID1のセマフォ資源に残りはなく、タスクAはID1のセマフォ資源を獲得できない。

図９は、時刻t7直前における３つのタスクの状態と資源の保有状況、および資源の状態を示す。
図９のタスク情報管理テーブルTITに示すように、タスクAは、IDが１であり、優先度が３であり、実行状態にあり、セマフォ資源は使用しておらず、メモリ資源を使用していることを示している。メモリ資源を使用していることは、タスク情報管理テーブルTITのフィールド３５にMEMTBLが記憶されていることにより示されている。

タスクBは、IDが２であり、優先度が５であり、待ち状態にあり、セマフォ資源を使用しており、ID1のメモリ資源が空くのを待っていることを示している。セマフォ資源を使用していることは、タスク情報管理テーブルTITのフィールド３４にSEMTBLが記憶されていることにより示されている。ID1のメモリ資源が空くのを待っていることは、タスク情報管理テーブルTITのフィールド３５に１が記憶されていることにより示されている。

タスクCは、IDが３であり、優先度が７であり、実行可能状態にあり、セマフォ資源を使用しており、メモリ資源が空くのは待っていないことを示している。セマフォ資源を使用していることは、タスク情報管理テーブルTITのフィールド３４にSEMTBLが記憶されていることにより示されている。メモリ資源が空くのを待っていないことは、タスク情報管理テーブルTITのフィールド３５に０が記憶されていることにより示されている。

図９のオブジェクト情報管理テーブルOITは、ワーニング事象通知部１２によって、ログ情報を受信する度に最新の状態に更新される。

図９の資源情報管理テーブルRIT（SEMTBL）に示すように、ID1のセマフォ資源については、フィールド４２にそれぞれ、ID2に対応する２とID3に対応する３とが記憶されていることから、タスクID２のタスクBとタスクID３のタスクCによって使用されており、フィールド４３には、それぞれのタスクがID1のセマフォ資源を獲得したときのプログラムカウンタのアドレス（すなわち位置）が記憶されている。

ID1のセマフォ資源は、２つのタスクを超えて使用はできないので、残り資源が無い(ゼロ)である。

図９の資源情報管理テーブルRIT（MEMTBL）に示すように、ID1のメモリ資源については、フィールド４２に、ID1に対応する１が記憶されていることから、ID1のタスクAによって使用されており、フィールド４３には、タスクAがID1のメモリ資源を獲得したときのプログラムカウンタのアドレス（すなわち位置）が記憶されている。

ID1のメモリ資源は、１つのタスクを超えて使用はできないので、残り資源が無い(ゼロ)である。

図９に示すような状態で、時刻t7において、タスクAが、ID1のセマフォオブジェクトの獲得のためにサービスコール「wai_sem」を発行すると、その結果、OS１６は、ID1のセマフォ資源の残りが無いために、資源獲得失敗の処理を行う。

この資源獲得失敗のイベントの発生により、ログ生成部１８は、図１０に示すログ情報LDを出力する。図１０のログ情報LDは、上記のサービスコールの発行のイベントに応じて生成され、ログ出力部１７を介して、ホストコンピュータ２のワーニング事象解析部１２に入力される。

図１０は、資源獲得失敗のイベントにおいて生成されるログ情報LDの例を示す図である。図１０のログ情報LDは、セマフォの獲得のためのサービスコールについて、サブコードにおいて「獲得失敗」の結果であったこと、獲得しようとした資源は「セマフォID1」であり、獲得しようとしたタスクは、「タスクID1」であり、プログラムカウンタは「当該サービスコールを発行したときのアドレス」であることを示している。特に、サブコード２２は、サービスコールの発行に対して、資源の獲得に失敗したことを示すエラーコードである。後述するように、このエラーコード２２に基づいて、タスクが資源の獲得に失敗したことが判定される。

ワーニング事象通知部１２は、ログ情報LDを受信すると、所定の処理を実行する。図１１は、ワーニング事象通知部１２がログ情報LDを受信したときの処理の流れの例を示すフローチャートである。

図１１を用いて、上述したサービスコールによる資源の獲得に失敗したときに、ワーニング事象通知部１２がデッドロックの発生を検出する処理について説明する。

まず、ワーニング事象通知部１２は、受信したログ情報LDから、ログ情報のイベントはサービスコールに関するものであるか否かを判定する（ステップS1）。ログ情報のイベントがサービスコールに関するものでないときは、ステップS1でNOとなり、処理は、その他の処理に移行する（ステップS2）。

ログ情報のイベントがサービスコールに関するものであるときは、ステップS1でYESとなり、ワーニング事象通知部１２は、サービスコールを発行したタスクが行った処理内容、すなわちサービスコールの内容を確認する（ステップS3）。この処理内容の確認は、ログ情報LDにおけるデータフィールド２１と２３を参照することによって行われる。

続いて、ワーニング事象通知部１２は、サービスコールの発行結果を確認する（ステップS4）。この発行結果の確認は、ログ情報LDにおけるデータフィールド２２を参照することによって行われる。

確認後、資源獲得のサービスコールが失敗しているか否かの判定がされる（ステップS5）。サービスコールが失敗していない場合は、ステップS5でNOとなり、続いて、サービスコールが正常に発行されて成功しているか否かの判定がされる(ステップS6)。ステップS1からS5の処理が、ログ情報LDを解析して、各タスクの状態、及び各タスクが使用する各資源の使用状態を検出するログ情報解析部を構成する。

ステップS6において、NOとなる場合、すなわち正常発行されなかったときは、処理は、その他の処理に移行する(ステップS7)。ステップS6において、YESとなる場合、すなわち正常発行されたときは、処理は、終了する。

ステップS5において、YESの場合、すなわち、資源獲得のためのサービスコールが、資源を獲得できずに失敗した場合、ワーニング事象通知部１２は、そのサービスコールを発行したタスクを確認し、タスク情報管理テーブルTITの中のそのタスクの状態をセマフォID1の待ち状態に更新する（ステップS8）。ステップS8の処理が、ログ情報LDを解析して得られたタスクの状態情報と資源の使用状態の情報を記憶するデータ記憶部１３の情報を更新する情報更新部を構成する。

図１２は、ステップS8の処理の結果の状態を示すタスク情報管理テーブルTITの内容を示す図である。図１２に示すように、タスクAについては、タスクが待ち状態にあり、ID1のセマフォ資源が空くのを待っていることを示す１の情報が、タスク情報管理テーブルTITに記憶されている。図１２において、タスクAについて、ID1のセマフォ資源が空くのを待っていることを示す１の情報は、資源が空くのを待っていることを示す空き待ち情報である。この空き待ち情報に基づいて、タスクがどの資源について空くのを待っているのかを検出することができる。

そして、ワーニング事象通知部１２は、タスク情報管理テーブルTITと資源情報管理テーブルRITとから、獲得に失敗した資源を保有するタスクを探索する（ステップS9）。タスクAがID1のセマフォ資源を獲得しようしているので、この探索は、図９の場合、タスク情報管理テーブルTITのフィールド３４を、例えば順番に、探索して、セマフォテーブルを参照していることを示す「SEMTBL」の有無をチェックし、さらに、そのセマフォの資源情報管理テーブルRIT(SEMTBL)のフィールド４２を、例えば、順番に探索して、資源を獲得しているタスクIDをチェックすることによって行われる。

図９の場合、まず、タスク情報管理テーブルTITから、タスクIDが２と３のフィールド３４に「SEMTBL」があり、さらに、セマフォの資源情報管理テーブルRIT(SEMTBL)のフィールド４２に、タスクIDが２と３のタスクがID1のセマフォを使用している。よって、ワーニング事象通知部１２は、タスクAが獲得に失敗した資源を保有しているのが、タスクBとCであることを判定することができる。

なお、図１１の処理では、図９のタスク情報管理テーブルTITのフィールド３４を順番に確認し、「SEMTBL」があれば、セマフォの資源情報管理テーブルRIT（SEMTBL）のフィールド４２を順番に確認するので、最初に、タスクBが、タスクAが獲得に失敗した資源を、保有していると判定する。

続いて、探索して得られたタスクは、サービスコールを発行したタスクが保有する資源の獲得待ちの状態にあるか否かが判断される（ステップS10）。この判断は、サービスコールを発行したタスクについて、タスク情報管理テーブルTITと資源情報管理テーブルRITをチェックすることによって行われる。

タスクAがそのサービスコールを発行したタスクであるので、図９の場合、ワーニング事象通知部１２は、タスク情報管理テーブルTITにおける、タスクAのレコードについて、使用している資源の有無をチェックし、さらに使用している資源は、メモリであるので、そのメモリについての資源情報管理テーブルRIT(MEMTBL)をチェックすると、ID1のメモリ資源をタスクAが使用していることが判断される。さらに、ID1のメモリ資源をタスクAが使用しているので、ワーニング事象通知部１２は、そのID1のメモリ資源を、タスクBが空くのを待っているか否かを、タスク情報管理テーブルTITにおけるタスクBのフィールド３５を確認することによって行う。タスクBについては、資源が空くのを待っていることを示す空き待ち情報として、ID1のメモリを待っていることを示す１がフィールド３５に記憶されている。

よって、図９に示す場合は、タスクAが獲得に失敗した資源（ID1のセマフォ資源）を保有するタスクBが、タスクAの保有する資源（ID1のメモリ資源）が空くのを待っていることなる。すなわち、ワーニング事象通知部１２は、タスクAとBの間で、資源の獲得におけるデッドロックが発生していることを、判定することができる。ステップS9とS10が、ログ情報LDの入力に応じて、各タスクの状態と各タスクが使用する資源の使用状態の情報に基づいて、タスク間でのデッドロック状態を検出するタスク状態検出部を構成する。

よって、ステップS10において、YESの場合、すなわち探索して得られたタスクは、サービスコールを発行したタスクが保有する資源の獲得待ちの状態にある場合、ワーニング事象通知部１２は、デッドロックが発生していること、出力装置４にメッセージ等を出力することによって、ユーザに通知する（ステップS11）。

さらに、ワーニング事象通知部１２は、獲得に失敗した資源を保有するタスクが、その資源を獲得したときのプログラムカウンタの値（アドレス）をデッドロック発生の原因推定位置として出力することによって、ユーザに通知し（ステップS12）、処理は終了する。ステップS11とS12が、タスク間でデッドロック状態が発生したことを示す発生情報を出力する発生情報出力部を構成する。

なお、ステップS10でNOの場合、すなわち、すなわち探索して得られたタスクが、サービスコールを発行したタスクが保有する資源の獲得待ちの状態にない場合、資源情報管理テーブルRIT中の全てのタスクについて、ステップS9及びS10の処理を終了したか否かが判断される（ステップS13）。

全てのタスクについてステップS9及びS10の処理が終了していない場合は、ステップS13でNOとなり、処理は、ステップS9に戻る。

以上のように、ワーニング事象通知部１２は、ステップS１からS8において、イベントの種類がサービスコールの発行である場合には、タスク情報管理テーブルTITの情報を更新する。また、ステップS5及びS6の処理において、サービスコール発行により資源獲得の成功を確認した場合は、そのまま処理を終了する。

そして、ワーニング事象通知部１２は、ステップS9,10,13において、デッドロックの対象となるタスクを検出し、ステップS11,12において、デッドロックの発生及びその発生の原因推測位置の情報を通知する処理を行う。なお、ワーニング事象通知部１２において受け取ったログの履歴を保管している場合は、通知する情報としては、デッドロックの発生及びその発生の原因推測位置の情報以外に、デッドロック発生時から所定の時間あるいは量だけ、過去に遡って1つあるいは複数のログ情報を出力するようにしてもよい。

なお、図８に示すように、タスクAとBの間においてデッドロックが発生した後、ターゲットボード３にあるOS１６を含むソフトウエアプログラムは実行を止めずに処理を続け、時刻t8でディスパッチのイベントが発生し、タスクCが実行状態になる。例えばタスクCが、この実行状態のタイミングで保有しているセマフォオブジェクトID1の資源を返却すると、タスクAは、その資源を獲得し再び目的の処理を開始することになる。

以上のように、本実施の形態に係るワーニング事象通知部１２を、ホストコンピュータ２に設け、デッドロックの検出および通知処理を行うようにしたため、OS１６を含むソフトウエアプログラムが高速に処理されている間においても、ほぼリアルタイムにデッドロックの検出と通知が可能になり、ユーザはデッドロックの発生を容易に認識することができる。

また、プログラムの処理は継続して実行されるため、あるタスク間にデッドロックが発生する場合でも、ユーザの判断でプログラムの停止あるいは継続、処理結果の妥当性判断が可能になる。更には、デッドロック状態の発生を探し出すために従来必要とされていた、プログラム実行停止後のログ解析の手間と知識、技術を必要としなくなる。

（第２の実施の形態）
次に、本発明の第２の実施の形態について説明する。以下、第２の実施の形態について、図面を用いて説明するが、プログラム開発システムの構成は、第１の実施の形態のシステムと同様であるので、第１の実施の形態と同じ構成要素については、同じ符号を用いて説明は省略する。本実施の形態では、ワーニング事象通知部１２が、プログラムの実行中に、タスク間に優先度の逆転現象が生じた場合に、その検出と発生の通知を行う。

以下、例を用いて説明する。図１３は、タスクと資源の状態の変化を説明するための図である。図１３は、優先度逆転現象が発生するまでの経過を示している。
図１３の例では、３つのタスクL，M，Nを含む、タスク及びハンドラにより構成されるアプリケーションプログラムにおいて、タスクLの優先度は３で、タスクMの優先度は５で、タスクNの優先度は７で、３つのタスクにおける優先度は以下の関係にある。

タスクL＞タスクM＞タスクN
さらに、本実施の形態では、セマフォ資源は、１つのタスクのみが使用できないものとする。
図１３は、この条件において、タスクLとMの間で発生する優先度逆転現象の発生の検出と、優先度逆転現象の発生を通知する例を示す。

図１３は、一般的なOSを利用するアプリケーションにおいて、優先度逆転現象の発生に対する対策処理がユーザあるいはOSによって行われていない場合における、優先度逆転現象の発生の事象が発生するまでの経過の例を示し、時刻t23において、ID1のセマフォ資源を、タスクLが獲得しようとした結果、タスクLとタスクMの間で優先度逆転現象が発生していることを示している。優先度逆転現象の発生については、後で詳述する。

時刻t21において、タスクLが待ち状態で、かつタスクMが実行可能状態であるときに、タスクNが実行状態においてセマフォ資源を獲得し、セマフォ資源の残りは０になった後に、ディスパッチが発生してタスクLに実行権が移動している。

さらに、時刻t23において、タスクLがセマフォ資源を獲得しようとしたが、セマフォ資源はタスクNが獲得しているので、獲得できず、その後の時刻t24において、ディスパッチが発生して、タスクMが実行状態になっている。すなわち、優先度の高いタスクLから、タスクLよりも優先度の低いタスクMが実行状態になっており、優先度逆転現象が発生している。

時刻t23の直前における３つのタスクL,M,Nの状態は、図１４に示す通りである。図１４は、図１３の場合におけるタスク情報管理テーブルTITと、セマフォの資源情報管理テーブルRITの状態を説明するための図である。図１４に示すように、タスクNはセマフォ資源を獲得しており、セマフォ資源の資源情報管理テーブルRITにも、ID1のセマフォ資源がタスクNによって獲得されていることを示すデータが記憶されている。

時刻t23において、タスクLがセマフォ資源を獲得しようとして、その獲得に失敗すると、第１の実施の形態において説明した図１０に示すようなログ情報LDが、ログ生成部１８により生成される。その結果、ワーニング事象通知部１２は、ログ出力部１７を介して、そのログ情報LDを取得する。

ワーニング事象通知部１２は、上述した図１１のステップS1において、そのログ情報LDを受信すると、上述した図１１の処理を実行するので、上述したデッドロックの発生していないことが確認される。

OS１６は、タスクLの状態が待ち状態に遷移したことに起因してタスクスケジューリングを行い、時刻t24においてタスクのディスパッチが発生する。このディスパッチのイベントにより、ログ生成部１８は、図１５に示すログ情報LDをワーニング事象解析部１２に供給する。ワーニング事象解析部１２は、受け取ったそのログ情報LDに基づいて図１６の処理を実行する。図１５は、ディスパッチの発生に基づいて生成されたログ情報の構成を示す図である。図１５のログ情報LDは、ディスパッチのイベントに応じて生成された情報である。図１６は、ディスパッチに応じて、実行される処理の流れの例を示すフローチャートである。このとき、イベントの種類は、ディスパッチの発生である。

図１１のステップS1において、ログ情報のイベントがディスパッチである場合、NOとなって、処理は、ステップS2へ移行する。ステップS2の処理は、図１６に示す処理を含む。

図１６のステップS21において、ログ情報LDがディスパッチに関するか否かが判断され、ディスパッチに関するものなければ、処理は、その他の処理へ移行する（ステップS22）。ステップS21の処理が、ログ情報LDを解析して、各タスクの状態、及び各タスクが使用する各資源の使用状態を検出するログ情報解析部を構成する。

ワーニング事象通知部１２は、ログ情報LDがディスパッチに関するものである場合、データ記憶部１３におけるタスク情報管理テーブルTITにおいて、ディスパッチ後のタスクIDのタスクを実行状態に更新し、かつディスパッチ前のタスクIDのタスクを実行可能状態に更新する（ステップS23）。図１３の場合、ワーニング事象通知部１２は、タスクMを実行可能状態から実行状態に更新し、ディスパッチ前のタスクである実行タスクLを実行状態から待ち状態に更新する。ステップS23の処理が、ログ情報LDを解析して得られたタスクの状態情報と資源の使用状態の情報を記憶するデータ記憶部１３の情報を更新する情報更新部を構成する。

図１７は、ステップS２３の処理後のタスク情報管理テーブルTITの内容を示す図である。図１７に示すように、タスクＬについては、待ち状態になり、かつ、ID1のセマフォ情報の開放を待っていることを示す１に更新され、タスクMについては、実行状態になっていることを示す情報に更新されている。

次に、ワーニング事象通知部１２は、ディスパッチ後に実行状態のタスクよりも優先度が高いタスクであって、かつ待ち状態のタスクを探索する（ステップS24）。

ワーニング事象通知部１２は、図１７に示すように、タスク情報管理テーブルTITを参照することによって、ディスパッチ後に実行状態のタスクMよりも優先度が高いタスクであって、かつ待ち状態のタスクとして、タスクLを探索して抽出する。

次に、ワーニング事象通知部１２は、その待ち状態のタスクが、低い優先度のタスクが保有する資源の開放を待っているか否かを判断する（ステップS25）。

本例では、待ち状態のタスクLが、優先度の低いタスクNが保有する資源の開放を待っていることが検出される。ステップS24とS25が、ログ情報LDの入力に応じて、各タスクの状態と、各タスクが使用する資源の使用状態の情報に基づいて、タスク間での優先度逆転状態の発生を検出するタスク状態検出部を構成する。

よって、その場合、ステップS25でYESの場合となって、ワーニング事象通知部１２は、実行状態のタスクと、資源の開放を待っているタスク間で優先度逆転の現象が発生していることを、メッセージデータ等を出力装置４に出力することによって、ユーザに通知する（ステップS26）。

そして、ワーニング事象通知部１２は、優先度の高いタスクが資源獲得に失敗し、優先度の低いタスクがその資源を獲得したときのプログラムカウンタの値を、資源情報管理テーブルRITから読み出して、優先度逆転現象発生の原因推定位置として通知する（ステップS27）。ステップS26とS27が、タスク間で優先度逆転状態が発生したことを示す発生情報を出力する発生情報出力部を構成する。

以上のように、図１６の処理によれば、ワーニング事象通知部１２は、イベントの種類がディスパッチの発生である場合、タスク情報管理テーブルTITの情報を更新し、さらに、ステップS24、S25において、優先度逆転の対象となるタスクを検出し、ステップS26,S27において、優先度逆転の発生と、その発生の原因推測位置を通知する。

よって、本実施の形態に係るホストコンピュータ２はワーニング事象通知部１２を備えて、優先度逆転現象の発生の検出およびその通知処理を行うため、OS１６を含むソフトウエアプログラムが高速に処理されている間においても、ほぼリアルタイムに優先度逆転現象の発生の検出とその通知を可能となり、ユーザは優先度逆転現象の発生を容易に認識することができる。更には、ユーザは、優先度逆転現象の発生を探し出すために従来必要とされていた、プログラム実行停止後のログ解析の手間、知識、及び技術を必要としなくなる。

（第３の実施の形態）
次に、本発明の第３の実施の形態について説明する。以下、第３の実施の形態について、図面を用いて説明するが、第１の実施の形態と同じ構成要素については、同じ符号を用いて説明は省略する。本実施の形態では、開発者が所望する特定の状態を示す情報を通知条件として設定することができ、ワーニング事象通知部１２が、その設定された条件に合致するか否かの解析を行い、条件に合致したときに、条件に合致したことを通知する。

以下、例を用いて説明する。図１８は、本実施の形態に係わるプログラム開発システムの構成を示す構成図である。
図１８に示すように、プログラム開発システム１Aは、入力装置５を有し、ワーニング事象通知部１２Aは、通知条件管理部１２ａと、通知条件解析部１２ｂとを含む。ワーニング事象通知部１２Aは、外部から、ここでは入力装置５から、設定された通知条件と、データ記憶部１３Aの解析情報の状態とが、一致したときには、ワーニング事象通知部１２Aが、出力装置４に通知条件と解析情報の状態が一致したことを、ユーザに通知するための出力信号を出力する。

通知条件管理部１２ａは、ユーザによって入力装置５から入力された通知条件の情報を、データ記憶部１３Aの通知条件記憶部１３ｃに記憶し、設定する。すなわち、通知条件管理部は、通知条件として１以上のタスク及び１以上の資源の少なくとも１つの状態を、通知条件記憶部１３ｃに設定し記憶するための処理部である。また、その設定された通知条件が変更されれば、通知条件管理部１２ａは、通知条件記憶部１３ｃに記憶された通知条件のデータの変更を行う。通知条件管理部１２ａは、通知条件として１以上のタスク及び１以上の資源の少なくとも１つの状態を設定し記憶する通知条件管理部を構成する。

通知条件解析部１２ｂは、通知条件の書式情報から、通知条件の意味を解析する処理部である。通知条件解析部１２ｂは、ログ情報LDの入力に応じて、データ記憶部１３Aに記憶された各タスクの状態あるいは資源の使用状態が、通知条件に一致するか否かを判断する通知条件一致判断部を構成する。

通知条件は、データ記憶部１３Aに記憶されたタスク情報記憶部１３ａと、資源情報記憶部１３ｂとに記憶されたデータに関して、通知を要求するオブジェクトの状態を、タスクIDと列、列と数量、等により指定される。

ここでは、ユーザの利便性を考慮して、各テーブルの各列にユニークな識別名を付与することによって、ユーザにとって通知条件の可読性を良くして、通知条件の認識、設定及び変更が容易にしている。

具体的には、タスク情報管理テーブルTITにおいて、タスクIDをTSKID、優先度をPRI、タスクの状態をSTATE、セマフォ資源の保有情報をSEM、そして、メモリ資源の保有情報をMEMとしている。
また、資源情報管理テーブルRITにおいては、オブジェクトの種類毎に、各列が識別される。セマフォIDをSEMID、セマフォ資源を獲得したタスクIDをGETID_SEM、その獲得した位置をGETPC_SEM、メモリIDをMEMID、メモリ資源を獲得したタスクIDをGETID_MEM、その資源を獲得した位置をGETPC_MEMとしている。

通知条件は、ここでは、次のような２つの書式で与えることとする。
書式A）
ID識別名(id)=識別名(条件[,number])[,識別名(条件[,number])]
書式Ｂ）
ID識別名(id)=number
ここで、[]内は省略することができる。

以下に例を示すが、通知条件として、各オブジェクト情報管理テーブルに保管されるデータが指定される。さらに、書式A)あるいはB)を and や or で接続することができ、2つあるいはそれ以上をandで接続する場合は、接続される各書式が表現するオブジェクトの状態をすべて満たす場合を検出し、orで接続する場合は、接続される各書式で表現するオブジェクトの状態のいずれかを満たす場合を検出する。以下に、いくつかの指定例を示す。

例１）タスクID1が待ち状態になったことを検出したい場合:
TSKID(1)=STATE(WAITING)
例２）タスクID2がセマフォID1の開放待ち状態で、且つタスクID3がセマフォID1を保有し、実行状態になったことを検出したい場合:
TSKID(2)=SEM(1),STATE(WAITING) and TSKID(3)=STATE(RUNNING) and
SEMID(1)=GETID_SEM(3)
例３）セマフォID2が3つ獲得されたことを検出したい場合:
SEMID(2)= 3
例４）セマフォID1がタスクID3によって2つ獲得されたことを検出したい場合:
SEMID(1)=GETID_SEM(3,2)
例５）タスクID1が実行状態、あるいはタスクID2が実行状態になったことを検出したい場合:
TSKID(1)=STATE(RUNNING) or TSKID(2)=STATE(RUNNING)
このような書式の通知条件は、入力装置５から入力され、通知条件管理部１２ａによって、データ記憶部１３Aの通知条件記憶部１３ｃに記憶される。なお、通知条件を入力するタイミングは、ターゲットボード３において、OS１６を含むソフトウエアプログラムが実行中の時、通知条件管理部１２ａから通知条件記憶部１３ｃに通知条件の情報を保管することが可能である。なお、通知条件管理部１２ａに通知条件の情報を渡す方法は、前記の入力装置５から入力する方法に限らず、ソフトウエアプログラム開発ツール１１にインターフェース部を設け、ソフトウエアプログラム開発ツール１１から通知条件の情報を入力するようにしてもよい。

ワーニング事象通知部１２Aでは、第１の実施の形態及び第２の実施の形態において示した図１１及び図１６の処理の終了に引き続いて、図１９の処理を実行することにより、条件一致の検出とその通知を行うことができる。

図１９は、第３の実施の形態に係わる処理の流れの例を示すフローチャートである。
まず、ワーニング事象通知部１２Aは、データ記憶部１３Aの通知条件記憶部１３ｃに記憶されている通知条件を参照する（ステップS31）。

その参照の結果、ワーニング事象通知部１２Aは、通知条件記憶部１３ｃに通知条件が記憶すなわち保管されているか否かを判断する（ステップS32）。通知条件が記憶されていなければ、ステップS32でNOとなり、処理は終了する。

通知条件が１つ以上記憶されているときは、ステップS32でYESの場合となり、ワーニング事象通知部１２Aは、通知条件解析部１２ｂを用いて、通知条件記憶部１３ｃに記憶された通知条件を一つずつ抽出して通知条件を解析する（ステップS33）。この解析において、通知条件の書式から条件の意味が得られる。ステップS33は、記憶された通知条件を解析する通知条件解析部を構成する。

そして、ワーニング事象通知部１２Aは、通知条件解析部１２ｂによって得られた解析情報に基づいて、抽出した通知条件におけるID識別名を、タスク情報管理テーブルTITあるいは資源情報管理テーブルRITから探索する（ステップS34）。
ワーニング事象通知部１２Aは、探索の結果得られたオブジェクト情報管理テーブルにおけるID識別名があれば、そのID識別名のオブジェクトについての状態情報と、通知条件とが一致するか否かの判断を行う（ステップS35）。

ID識別名のオブジェクトについての状態情報と通知条件とが一致する場合、ステップS35でYESとなり、ワーニング事象通知部１２Aは、条件一致を通知し（ステップS36）、処理は終了する。すなわち、ワーニング事象通知部１２Aは、設定された通知条件に一致した状態が発生したことを通知するために、所定のメッセージ等の出力信号を出力装置４に出力する。ステップS36は、通知条件解析部１２ｂによって、データ記憶部１３Aに記憶された各タスクの状態あるいは資源の使用状態が、通知条件に一致すると判断されたときに、所定の情報を出力する一致情報出力部を構成する。

また、ID識別名のオブジェクトについての状態情報と通知条件とが一致しない場合、あるいはID識別名のオブジェクトについての状態情報が存在しない場合は、ステップS35でNOとなり、ワーニング事象通知部１２Aは、抽出した通知条件の全てについてステップS34及びS35の処理を実行したか否かを判断する（ステップS37）。

抽出した通知条件の全てについてステップS34及びS35の処理を実行していれば、ステップS37においてYESの場合となり、処理は終了する。抽出した通知条件の全てについてステップS34及びS35の処理を実行していないときは、ステップS37でNOとなり、処理は、ステップS34に移行する。

以上のように、本実施の形態によれば、ステップS31とS32において、所定の書式の通知情報の入力が確認される。そして、通知条件管理部１２ａによって、データ記憶部１３Aの通知条件記憶部１３ｃに、通知条件の情報が保持されている場合は、ステップS33において、通知条件解析部１２ａを用いて書式情報を解析し、通知条件の意味理解が行われる。解析された通知条件の情報を用いて、ステップS34からS37の処理においてオブジェクト情報管理テーブルOITから、通知が要求されているオブジェクトの状態情報を探し出す。そして、得られたオブジェクトの状態と条件とが一致した場合は、ステップS36においてその条件一致の発生したことを通知する。

上述したように、第１の実施の形態あるいは第２の実施の形態において、デッドロックあるいは優先度逆転現象の通知が必要としない場合においても、図１１のステップS8よりも後の処理、及び図１６のステップS23よりも後の処理は実行されず、図１９の処理が実行されるので、開発者が知りたいオブジェクト状態、すなわち開発者が所望する特定の状態だけを検出することができる。

以上のように、第３の実施の形態によれば、ユーザは、OS１６が管理する１以上のオブジェクトについて、ある所望の特定の状態を検出するにあたり、OS１６の管理項目と検出したい条件内容により指定することができる。特に、上述した通知条件の設定方法によれば、開発者であるユーザは、メモリ、レジスタ等を意識する必要がなくなり、開発者にとっては通知条件の可読性及び設定操作性が良い。

また、その条件を任意のタイミングで入力装置５から入力することができ、かつワーニング事象通知部１２が、その条件に一致したときにほぼリアルタイムに、条件一致の検出とその通知をできる。そのため、従来のように、プログラム実行停止後にログ解析してその条件を探す、あるいは変数、メモリ、レジスタの変化の検出を組み合わせて条件に一致する状態を探し出す、といった作業の手間や知識、技術を必要としなくなる。

以上のように、上述した各実施の形態のデバッグ装置によれば、プログラムの開発時に、デッドロックの発生あるいは優先度逆転現象の発生を検出することができる。

なお、本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明した。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。

本発明の第１の実施の形態に係わるプログラム開発システムの構成を示す構成図である。本発明の第１の実施の形態に係るタスクの状態遷移図である。本発明の第１の実施の形態に係るログ情報のデータフォーマットの構成を示す図である。本発明の第１の実施の形態に係る、サービスコール利用時におけるログ情報の例を示す図である。本発明の第１の実施の形態に係る、タスクのディスパッチ時におけるログ情報の例を示す図である。本発明の第１の実施の形態に係る、タスク情報管理データのデータフォーマットの構成を示す図である。本発明の第１の実施の形態に係る、資源情報管理データのデータフォーマットの構成を示す図である。本発明の第１の実施の形態に係る、タスクと資源の状態の変化を説明するための図である。図８の場合におけるタスク情報管理テーブルと、セマフォとメモリの各資源情報管理テーブルの状態を説明するための図である。資源獲得失敗のイベントにおいて生成されるログ情報の例を示す図である。ワーニング事象通知部がログ情報を受信したときの処理の流れの例を示すフローチャートである。図１１における、ステップS8の処理の結果の状態を示すタスク情報管理テーブルの内容を示す図である。本発明の第２の実施の形態に係る、タスクと資源の状態の変化を説明するための図である。図１３の場合におけるタスク情報管理テーブルと、セマフォの資源情報管理テーブルの状態を説明するための図である。本発明の第２の実施の形態に係る、ディスパッチの発生に基づいて生成されたログ情報の構成を示す図である。本発明の第２の実施の形態に係る、ディスパッチに応じて実行される処理の流れの例を示すフローチャートである。図１６における、ステップS２３の処理後のタスク情報管理テーブルの内容を示す図である。本発明の第３の実施の形態に係わるプログラム開発システムの構成を示す構成図である。本発明の第３の実施の形態に係わる処理の流れの例を示すフローチャートである。

符号の説明

１、１A プログラム開発システム、２、２A ホストコンピュータ、３ターゲットボード、４出力装置、５入力装置、１１プログラム開発ツール、１２、１２A ワーニング事象通知部、１２ａ通知条件管理部、１２ｂ通知条件解析部、１３データ記憶部、１３ａタスク情報記憶部、１３ｂ資源情報記憶部、１３ｃ通知条件記憶部、１５アプリケーションプログラム、１６ＯＳ、１７ログ出力部、１８ログ生成部、１９ケーブル

Claims

プログラムの実行中にオペレーティングシステムにおいて発生するイベントに応じて生成されるログ情報を解析して、前記プログラムの各タスクの状態と前記各タスクが使用する資源の使用状態を検出するログ情報解析部と、
該ログ情報解析部によって解析して得られた前記各タスクの状態の情報と前記各タスクが使用する資源の使用状態の情報を記憶する状態情報記憶部と、
前記ログ情報の入力に応じて、前記各タスクの状態と前記各タスクが使用する資源の使用状態の情報に基づいて、タスク間でのデッドロック状態またはタスク間での優先度逆転状態の発生を検出するタスク状態検出部と、
該タスク状態検出部によって検出された前記タスク間でのデッドロック状態または前記タスク間での優先度逆転状態が発生したことを示す発生情報を出力する発生情報出力部と、
を有することを特徴とするデバッグ装置。
前記各タスクの状態の情報は、前記各タスクを識別するためのタスク識別情報と、前記各タスクの状態を示す状態情報と、前記各タスクの資源の獲得及び空き待ちの状態を示す資源獲得状態情報とを含み、
前記各タスクが使用する資源の使用状態の情報は、各資源を使用しているタスクの識別情報を含み、
前記タスク状態検出部は、前記タスク識別情報、前記状態情報、前記資源獲得状態情報及び前記各資源を使用しているタスクの識別情報に基づいて、第１の資源を保有する第１のタスクが第２の資源の獲得に失敗し、前記第２の資源を保有する第２のタスクが、前記第１のタスクが保有する前記第１の資源が空くのを、待っている状態にあることを検出することによって、前記タスク間でのデッドロック状態を検出することを特徴とする請求項１に記載のデバッグ装置。
前記各タスクの状態の情報は、前記各タスクを識別するためのタスク識別情報と、前記各タスクの優先度情報と、前記各タスクの状態情報と、前記各タスクの資源の獲得及び空き待ちの資源獲得状態情報とを含み、
前記タスク状態検出部は、前記タスク識別情報、前記状態情報及び前記資源獲得状態情報に基づいて、第１の資源が空くのを待っている第１のタスクよりも優先度の低い第２のタスクが、実行状態にあることを検出することによって、前記タスク間での優先度逆転状態の発生を検出することを特徴とする請求項１に記載のデバッグ装置。
通知条件として１以上のタスク及び１以上の資源の少なくとも１つの状態を設定し記憶する通知条件管理部と、
前記ログ情報の入力に応じて、前記状態情報記憶部に記憶された前記各タスクの状態あるいは前記資源の使用状態が、前記通知条件に一致するか否かを判断する通知条件一致判断部と、
前記通知条件一致判断部によって、前記状態情報記憶部に記憶された前記各タスクの状態あるいは前記資源の使用状態が、前記通知条件に一致すると判断されたときに、所定の情報を出力する一致情報出力部とを有することを特徴とする請求項１に記載のデバッグ装置。
プログラムの実行中にオペレーティングシステムにおいて発生するイベントに応じて生成されるログ情報を解析して、前記プログラムの各タスクの状態と前記各タスクが使用する資源の使用状態を検出し、
解析して得られた前記各タスクの状態の情報と前記各タスクが使用する資源の使用状態の情報）を記憶し、
前記ログ情報の入力に応じて、前記各タスクの状態と前記各タスクが使用する資源の使用状態の情報に基づいて、タスク間でのデッドロック状態またはタスク間での優先度逆転状態の発生を検出し、
検出された前記タスク間でのデッドロック状態または前記タスク間での優先度逆転状態が発生したことを示す発生情報を出力する、
ことを特徴とするデバッグ方法。