JPH0922370A - マルチスレッド・ターゲット・プログラムのメモリ・アクセス・チェック方法及び装置 - Google Patents
マルチスレッド・ターゲット・プログラムのメモリ・アクセス・チェック方法及び装置Info
- Publication number
- JPH0922370A JPH0922370A JP8044104A JP4410496A JPH0922370A JP H0922370 A JPH0922370 A JP H0922370A JP 8044104 A JP8044104 A JP 8044104A JP 4410496 A JP4410496 A JP 4410496A JP H0922370 A JPH0922370 A JP H0922370A
- Authority
- JP
- Japan
- Prior art keywords
- memory
- program
- debugger
- multithreaded
- status information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/362—Debugging of software
- G06F11/366—Debugging of software using diagnostics
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/362—Debugging of software
- G06F11/3636—Debugging of software by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/362—Debugging of software
- G06F11/3644—Debugging of software by instrumenting at runtime
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
- Multi Processors (AREA)
Abstract
(57)【要約】
【課題】 「マルチスレッド・アプリケーション・プロ
グラムに対する有効なメモリ・アクセスの実行時チェッ
ク・デバッガ」（以下、「ＲＴＣ／ＭＴ」と呼ぶ）のた
めのシステムおよび方法を提供する。 【解決手段】 シリアルまたは並行のいずれかで作動す
る複数のスレッドを含んでいる実行時プロセスをデバッ
ガ・プログラムによって監視し、メモリ・アクセス・エ
ラーが検出され、それをエラーに遭遇したプロセス・ス
レッドに適正に帰属させる。本発明のＲＴＣ／ＭＴシス
テムは必要に応じマルチスレッド・ターゲット・プログ
ラムに関するメモリ漏れを監視し、報告する装置および
方法も提供する。
グラムに対する有効なメモリ・アクセスの実行時チェッ
ク・デバッガ」（以下、「ＲＴＣ／ＭＴ」と呼ぶ）のた
めのシステムおよび方法を提供する。 【解決手段】 シリアルまたは並行のいずれかで作動す
る複数のスレッドを含んでいる実行時プロセスをデバッ
ガ・プログラムによって監視し、メモリ・アクセス・エ
ラーが検出され、それをエラーに遭遇したプロセス・ス
レッドに適正に帰属させる。本発明のＲＴＣ／ＭＴシス
テムは必要に応じマルチスレッド・ターゲット・プログ
ラムに関するメモリ漏れを監視し、報告する装置および
方法も提供する。
Description
【０００１】
【発明の属する技術分野】本発明はマルチプロセッシン
グ・コンピュータ、マルチスレッド・コンピュータ・シ
ステムの開発および実行時デバッグに関する。詳細にい
えば、本発明はターゲット・マルチスレッド・システム
の実行時メモリ・アクセス・チェックの方法および装置
に関する。
グ・コンピュータ、マルチスレッド・コンピュータ・シ
ステムの開発および実行時デバッグに関する。詳細にい
えば、本発明はターゲット・マルチスレッド・システム
の実行時メモリ・アクセス・チェックの方法および装置
に関する。
【０００２】
【従来の技術】本願に記載する発明はWayne C.Gramlic
h,Sunnyvale,CA.:Achut Reddy,San Jose,CA.:およびShy
am Desirazu,Foster City,CA.による「Method and Appa
ratus for Run-Time Error Checking Using Dynamic Pa
tching」なる名称の１９９４年１月２８日出願の米国特
許願第０８／１８９，０８９号に記載されているデバッ
ガ・システムに関し、またThomas Preisler,Wayne C.Gr
amlich,Eduardo PelegriLlopartおよびTerrence Miller
による「Method and Apparatus for a Fast Debugger Fi
x & Continue Operation」なる名称の１９９４年９月１
日出願の米国特許一部継続出願第０８／２９９，７２０
号に記載されているシステムに関するものである。上記
の出願は両者とも参照することによって、本明細書の一
部となる。
h,Sunnyvale,CA.:Achut Reddy,San Jose,CA.:およびShy
am Desirazu,Foster City,CA.による「Method and Appa
ratus for Run-Time Error Checking Using Dynamic Pa
tching」なる名称の１９９４年１月２８日出願の米国特
許願第０８／１８９，０８９号に記載されているデバッ
ガ・システムに関し、またThomas Preisler,Wayne C.Gr
amlich,Eduardo PelegriLlopartおよびTerrence Miller
による「Method and Apparatus for a Fast Debugger Fi
x & Continue Operation」なる名称の１９９４年９月１
日出願の米国特許一部継続出願第０８／２９９，７２０
号に記載されているシステムに関するものである。上記
の出願は両者とも参照することによって、本明細書の一
部となる。
【０００３】コンピュータ・システムの開発は従来のユ
ニプロセッサ・システムから、所与のコンピュータ・シ
ステム内に複数の中央演算処理装置（ＣＰＵ）を備えて
いるシステムを使用することに進んできている。このよ
うなシステムを「マルチプロセッサ」ハードウェア・シ
ステムと呼ぶ。オペレーティング・システムを含むプロ
グラミング・システムは数個のＣＰＵで同時に実行でき
る複数のスレッドを使用するアプリケーション・プログ
ラムを開発できるようにすることによって、システムの
複数のＣＰＵを利用するように設計されている。このこ
とは２つ以上のＣＰＵで同時に作動するアプリケーショ
ンのさまざまな部分を同期化する付加的な制御機構を必
要とする。このような新しいプログラミング能力は一般
に、「マルチスレッディング」と呼ばれる新しいプログ
ラミング・パラダイムで実施されている。「制御のスレ
ッド」ないし簡単には「スレッド」とはプログラムで実
行される一連の命令である。スレッドはローカル変数お
よび復帰アドレスを追跡するためのプログラム・カウン
タ（ＰＣ）およびスタックを有している。各スレッドは
独立して実行される。スレッドはプロセス命令とそのデ
ータのほとんどを共用し、またプロセスのオペレーティ
ング・システム状態のほとんどを共用している。各スレ
ッドは任意のシステム・コールを行うことができる。マ
ルチスレッド・システムのスレッドおよび関連する制御
およびサービス（同期化サービスを含む）をオブジェク
トとして実施することもできる。オブジェクトとして実
施される同期化技法には、相互排除（ｍｕｔｅｘ）ロッ
ク、セマフォ、条件変数、およびリーダーズ／ライター
・ロックなどがある。アプリケーション・プログラムに
適用されるマルチスレッドの詳細については、M.L.Powe
ll,S.R.Kleiman,S.Barton,D.Shan,D.Stein,M.Weeksの「S
unOS Multi-thread Architecture」、Proceedingsof USEN
IX Conference,Winter '91,Dallas,TXという論文の第６
５ページ−第７９ページを参照されたい。また、上述の
Silbershatz 他のテキスト、第９６−第９７ページ、お
よび第５９７−第６２９ページを参照されたい。
ニプロセッサ・システムから、所与のコンピュータ・シ
ステム内に複数の中央演算処理装置（ＣＰＵ）を備えて
いるシステムを使用することに進んできている。このよ
うなシステムを「マルチプロセッサ」ハードウェア・シ
ステムと呼ぶ。オペレーティング・システムを含むプロ
グラミング・システムは数個のＣＰＵで同時に実行でき
る複数のスレッドを使用するアプリケーション・プログ
ラムを開発できるようにすることによって、システムの
複数のＣＰＵを利用するように設計されている。このこ
とは２つ以上のＣＰＵで同時に作動するアプリケーショ
ンのさまざまな部分を同期化する付加的な制御機構を必
要とする。このような新しいプログラミング能力は一般
に、「マルチスレッディング」と呼ばれる新しいプログ
ラミング・パラダイムで実施されている。「制御のスレ
ッド」ないし簡単には「スレッド」とはプログラムで実
行される一連の命令である。スレッドはローカル変数お
よび復帰アドレスを追跡するためのプログラム・カウン
タ（ＰＣ）およびスタックを有している。各スレッドは
独立して実行される。スレッドはプロセス命令とそのデ
ータのほとんどを共用し、またプロセスのオペレーティ
ング・システム状態のほとんどを共用している。各スレ
ッドは任意のシステム・コールを行うことができる。マ
ルチスレッド・システムのスレッドおよび関連する制御
およびサービス（同期化サービスを含む）をオブジェク
トとして実施することもできる。オブジェクトとして実
施される同期化技法には、相互排除（ｍｕｔｅｘ）ロッ
ク、セマフォ、条件変数、およびリーダーズ／ライター
・ロックなどがある。アプリケーション・プログラムに
適用されるマルチスレッドの詳細については、M.L.Powe
ll,S.R.Kleiman,S.Barton,D.Shan,D.Stein,M.Weeksの「S
unOS Multi-thread Architecture」、Proceedingsof USEN
IX Conference,Winter '91,Dallas,TXという論文の第６
５ページ−第７９ページを参照されたい。また、上述の
Silbershatz 他のテキスト、第９６−第９７ページ、お
よび第５９７−第６２９ページを参照されたい。
【０００４】
【発明が解決しようとする課題】ユニプロセッサ（すな
わち、シングルＣＰＵ）用に作成されたデバッガ・プロ
グラムは一般に、マルチスレッド・モードで機能するよ
うに作成されたアプリケーション・プログラムをテスト
する場合に正常に機能しない。今までに、実行時にメモ
リ・アクセスをチェックするデバッグ・システムを開発
する試みがなされてきたが、これらのデバッガはユニプ
ロセッサ・ベースのアプリケーション・プログラムを念
頭において設計されている。このような試みの１つはオ
ブジェクト・コード・モジュール内であらゆるメモリ・
アクセス命令に隣接している付加的な命令をインターリ
ーブし、拡張された、あるいは新しいオブジェクト・コ
ード・モジュールをロードし、かつ実行して、拡張また
は新規オブジェクト・コード・モジュールの実行時にア
ドレスされたメモリ・ロケーションの状態をテストする
ものであった。この方法はPure Software,Inc.のＰｕｒ
ｉｆｙプログラムによって使用されており、このプログ
ラムは１９９３年３月９日発行の米国特許第５，１９
３，１８０号および１９９４年８月２日発行の同第５，
３３５，３４４号に記載されている。Ｐｕｒｉｆｙシス
テムはコンパイラによって作成されたオブジェクト・モ
ジュールを読み取り、命令を元のオブジェクト・コード
・モジュールのあらゆるメモリ・アクセス命令に対する
ターゲット・オブジェクト・モジュールのコードにイン
ターリーブし、これによって、関連するオブジェクト・
コードおよびライブラリ・モジュールにリンクされ、コ
ンピュータにロードされ、実行される新しい拡張オブジ
ェクト・モジュールを作成するものである。このＰｕｒ
ｉｆｙの手法はシングルスレッド・アプリケーション・
プログラム用に設計されたものであり、マルチスレッド
用に設計されたターゲット・アプリケーションのテスト
が不正確なものとなることが示されている。これは各ス
レッドがそれ自体のプログラム・カウンタ（ＰＣ）とス
タックを有しており、デバッガがこれらの別々なスタッ
クを取り扱い、エラーを含んでいる特定のスレッドにし
たがってエラーを報告できなければならないことによる
ものである。本願の出願人であるＳｕｎ Ｍｉｃｒｏｓ
ｙｓｔｅｍｓ，Ｉｎｃ．はＳＰＡＲＣＷｏｒｋｓという
名称で販売している、数種類の開発ツールを集めたもの
である自身のｄｂｘデバッガ、すなわち実行時チェック
（Ｒｕｎ−Ｔｉｍｅ−Ｃｈｅｃｋｉｎｇ：ＲＴＣ）シス
テムに実行時チェック機能を有している。Ｐｕｒｉｔｙ
の製品とは異なり、Ｓｕｎのデバッガ製品は元のオブジ
ェクト・コード・モジュールをデバッガの制御の下でコ
ンピュータにロードし、ターゲット・アプリケーション
を反映する処理を開始することによって、ターゲット・
アプリケーション上で作動する。実行時チェックをユー
ザが要求した場合には、デバッガのＲＴＣ部分があらゆ
るメモリ参照命令に、アクセスされているメモリ・ロケ
ーションの妥当性をテストするために設計された計装コ
ードとライブラリ・モジュールをオーバーレイする。し
かしながら、このＲＴＣシステム自体はもともとシング
ルスレッド・プロセスで作動するように設計されたもの
であり、このシステムもその独立したスタックおよびプ
ログラム・カウンタなどによって同時に作動している複
数のスレッドを取り扱うには変更を必要とする。実行時
デバッグ、特にメモリ・アクセス・チェック・ツールが
マルチスレッド・アプリケーション・プログラムに利用
できることが望ましい。
わち、シングルＣＰＵ）用に作成されたデバッガ・プロ
グラムは一般に、マルチスレッド・モードで機能するよ
うに作成されたアプリケーション・プログラムをテスト
する場合に正常に機能しない。今までに、実行時にメモ
リ・アクセスをチェックするデバッグ・システムを開発
する試みがなされてきたが、これらのデバッガはユニプ
ロセッサ・ベースのアプリケーション・プログラムを念
頭において設計されている。このような試みの１つはオ
ブジェクト・コード・モジュール内であらゆるメモリ・
アクセス命令に隣接している付加的な命令をインターリ
ーブし、拡張された、あるいは新しいオブジェクト・コ
ード・モジュールをロードし、かつ実行して、拡張また
は新規オブジェクト・コード・モジュールの実行時にア
ドレスされたメモリ・ロケーションの状態をテストする
ものであった。この方法はPure Software,Inc.のＰｕｒ
ｉｆｙプログラムによって使用されており、このプログ
ラムは１９９３年３月９日発行の米国特許第５，１９
３，１８０号および１９９４年８月２日発行の同第５，
３３５，３４４号に記載されている。Ｐｕｒｉｆｙシス
テムはコンパイラによって作成されたオブジェクト・モ
ジュールを読み取り、命令を元のオブジェクト・コード
・モジュールのあらゆるメモリ・アクセス命令に対する
ターゲット・オブジェクト・モジュールのコードにイン
ターリーブし、これによって、関連するオブジェクト・
コードおよびライブラリ・モジュールにリンクされ、コ
ンピュータにロードされ、実行される新しい拡張オブジ
ェクト・モジュールを作成するものである。このＰｕｒ
ｉｆｙの手法はシングルスレッド・アプリケーション・
プログラム用に設計されたものであり、マルチスレッド
用に設計されたターゲット・アプリケーションのテスト
が不正確なものとなることが示されている。これは各ス
レッドがそれ自体のプログラム・カウンタ（ＰＣ）とス
タックを有しており、デバッガがこれらの別々なスタッ
クを取り扱い、エラーを含んでいる特定のスレッドにし
たがってエラーを報告できなければならないことによる
ものである。本願の出願人であるＳｕｎ Ｍｉｃｒｏｓ
ｙｓｔｅｍｓ，Ｉｎｃ．はＳＰＡＲＣＷｏｒｋｓという
名称で販売している、数種類の開発ツールを集めたもの
である自身のｄｂｘデバッガ、すなわち実行時チェック
（Ｒｕｎ−Ｔｉｍｅ−Ｃｈｅｃｋｉｎｇ：ＲＴＣ）シス
テムに実行時チェック機能を有している。Ｐｕｒｉｔｙ
の製品とは異なり、Ｓｕｎのデバッガ製品は元のオブジ
ェクト・コード・モジュールをデバッガの制御の下でコ
ンピュータにロードし、ターゲット・アプリケーション
を反映する処理を開始することによって、ターゲット・
アプリケーション上で作動する。実行時チェックをユー
ザが要求した場合には、デバッガのＲＴＣ部分があらゆ
るメモリ参照命令に、アクセスされているメモリ・ロケ
ーションの妥当性をテストするために設計された計装コ
ードとライブラリ・モジュールをオーバーレイする。し
かしながら、このＲＴＣシステム自体はもともとシング
ルスレッド・プロセスで作動するように設計されたもの
であり、このシステムもその独立したスタックおよびプ
ログラム・カウンタなどによって同時に作動している複
数のスレッドを取り扱うには変更を必要とする。実行時
デバッグ、特にメモリ・アクセス・チェック・ツールが
マルチスレッド・アプリケーション・プログラムに利用
できることが望ましい。
【０００５】
【課題を解決するための手段】本発明はマルチスレッド
・アプリケーションがユニプロセッサでテストされるの
か、マルチプロセッサでテストされるのかにかかわりな
く、マルチスレッド・アプリケーション・プログラムを
テストでき、かつ数個の同時実行可能なスレッドのうち
どのスレッドがメモリ・アクセス・エラーを生じるのか
を正確に追跡でき、しかも問題箇所およびそこへアクセ
スしようとしているスレッドをユーザに正確に報告でき
る、マルチスレッド・アプリケーション用実行時チェッ
ク（RunTime Checking for Multi-Threaded applicatio
n: ＲＴＣ／ＭＴ）と呼ばれるメモリ・アクセス・チェ
ック・システムからなっている。
・アプリケーションがユニプロセッサでテストされるの
か、マルチプロセッサでテストされるのかにかかわりな
く、マルチスレッド・アプリケーション・プログラムを
テストでき、かつ数個の同時実行可能なスレッドのうち
どのスレッドがメモリ・アクセス・エラーを生じるのか
を正確に追跡でき、しかも問題箇所およびそこへアクセ
スしようとしているスレッドをユーザに正確に報告でき
る、マルチスレッド・アプリケーション用実行時チェッ
ク（RunTime Checking for Multi-Threaded applicatio
n: ＲＴＣ／ＭＴ）と呼ばれるメモリ・アクセス・チェ
ック・システムからなっている。
【０００６】本発明はそれ自体がマルチスレッドに安全
なメモリ・アクセス・チェック・システムを使用して、
マルチスレッド・ターゲット・プログラムをデバッグす
るための経済的で、高性能なシステムおよび方法を提供
することによって上述の欠点を解消する。具体的にいえ
ば、本発明の一態様によれば、マルチスレッド・ターゲ
ット・プログラムのメモリ・アクセス・チェック方法が
実施されたコンピュータにおいて、チェックを行うデバ
ッガ・プログラム自体がマルチスレッドに安全（「ＭＴ
安全」）であり、このＭＴ安全デバッガがターゲット・
プログラムによってメモリ・ロケーションが割当ておよ
び割当て解除されたときにこれらすべての状態を維持
し、その後、ターゲット・プログラムがメモリ・ロケー
ションにそのロケーションに対して無効とみなされる態
様でアクセスを試みたときに生じることのあるエラーを
報告するメモリ・アクセス・チェック方法について特許
が請求される。
なメモリ・アクセス・チェック・システムを使用して、
マルチスレッド・ターゲット・プログラムをデバッグす
るための経済的で、高性能なシステムおよび方法を提供
することによって上述の欠点を解消する。具体的にいえ
ば、本発明の一態様によれば、マルチスレッド・ターゲ
ット・プログラムのメモリ・アクセス・チェック方法が
実施されたコンピュータにおいて、チェックを行うデバ
ッガ・プログラム自体がマルチスレッドに安全（「ＭＴ
安全」）であり、このＭＴ安全デバッガがターゲット・
プログラムによってメモリ・ロケーションが割当ておよ
び割当て解除されたときにこれらすべての状態を維持
し、その後、ターゲット・プログラムがメモリ・ロケー
ションにそのロケーションに対して無効とみなされる態
様でアクセスを試みたときに生じることのあるエラーを
報告するメモリ・アクセス・チェック方法について特許
が請求される。
【０００７】本発明の第２の態様によれば、マルチスレ
ッド・ターゲット・プログラムのメモリ・アクセス・チ
ェックのためのコンピュータ・システムにおいて、マル
チスレッド・オペレーティング・システムとマルチスレ
ッド安全デバッガ機構がメモリ・ロケーションの状態を
維持するように作動し、かつこの状態をチェックし、タ
ーゲット・プログラムが無効な態様でロケーションにア
クセスしたときに生じるエラーを報告するコンピュータ
・システムについて特許が請求される。
ッド・ターゲット・プログラムのメモリ・アクセス・チ
ェックのためのコンピュータ・システムにおいて、マル
チスレッド・オペレーティング・システムとマルチスレ
ッド安全デバッガ機構がメモリ・ロケーションの状態を
維持するように作動し、かつこの状態をチェックし、タ
ーゲット・プログラムが無効な態様でロケーションにア
クセスしたときに生じるエラーを報告するコンピュータ
・システムについて特許が請求される。
【０００８】本発明の他の態様によれば、マルチスレッ
ド安全デバッガ・システムがメモリ漏れ状態を維持し、
必要に応じ、割り当てられてはいるが、ターゲット・プ
ログラムがアクセスできないメモリ・ロケーションと定
義される「メモリ漏れ」を示すエラーを報告する方法お
よびコンピュータ・システムについて特許が請求され
る。このような漏れはもはや使用されていない以前に割
り当てられたメモリを解放せずにルーチンが終了したこ
と、あるいは割り当てられたメモリに対するポインタが
何らかの理由で破壊または削除され、メモリ・ロケーシ
ョンにもはやアクセスできなくなったことのいずれかに
よって生じる。
ド安全デバッガ・システムがメモリ漏れ状態を維持し、
必要に応じ、割り当てられてはいるが、ターゲット・プ
ログラムがアクセスできないメモリ・ロケーションと定
義される「メモリ漏れ」を示すエラーを報告する方法お
よびコンピュータ・システムについて特許が請求され
る。このような漏れはもはや使用されていない以前に割
り当てられたメモリを解放せずにルーチンが終了したこ
と、あるいは割り当てられたメモリに対するポインタが
何らかの理由で破壊または削除され、メモリ・ロケーシ
ョンにもはやアクセスできなくなったことのいずれかに
よって生じる。
【０００９】本発明のシステムの目的、特徴および利点
は以下の説明から明らかとなろう。
は以下の説明から明らかとなろう。
【００１０】
表記および述語 以下の詳細な説明は主として、コンピュータ・メモリ内
のデータ・ビットにおける作動の手順および記号表示に
よって示されている。これらの手順の記述および表示は
データ処理分野の技術者によって自分達の作業をその分
野の他の技術者に最も効果的に伝えるために使用されて
いる手段である。
のデータ・ビットにおける作動の手順および記号表示に
よって示されている。これらの手順の記述および表示は
データ処理分野の技術者によって自分達の作業をその分
野の他の技術者に最も効果的に伝えるために使用されて
いる手段である。
【００１１】本明細書において、また一般に手順とは希
望する結果をもたらすステップの自己矛盾のないシーケ
ンスをいう。これらのステップは物理量の物理的操作を
必要とするものである。通常、必然的なものではない
が、これらの量は記憶、転送、組合せ、比較、あるいは
処理を行うことのできる電気信号または磁気信号の形を
とる。場合によっては、主として一般に使用されている
ことから、これらの信号をビット、要素、値、記号、文
字、項目、数字などと呼ぶことが都合がよいことがあ
る。しかしながら、これらや類似の用語がすべて適切な
物理量に関連づけられているものであって、これらの量
に適用された都合のよいラベルに過ぎないことを念頭に
おいておくべきである。
望する結果をもたらすステップの自己矛盾のないシーケ
ンスをいう。これらのステップは物理量の物理的操作を
必要とするものである。通常、必然的なものではない
が、これらの量は記憶、転送、組合せ、比較、あるいは
処理を行うことのできる電気信号または磁気信号の形を
とる。場合によっては、主として一般に使用されている
ことから、これらの信号をビット、要素、値、記号、文
字、項目、数字などと呼ぶことが都合がよいことがあ
る。しかしながら、これらや類似の用語がすべて適切な
物理量に関連づけられているものであって、これらの量
に適用された都合のよいラベルに過ぎないことを念頭に
おいておくべきである。
【００１２】さらに、遂行される操作は加算や比較など
の人間の操作員が行う知的な作業と一般的に関連づけら
れた用語で呼ばれることがしばしばある。このような人
間の操作員の能力はほとんどの場合必要のないものであ
ったり、あるいは望ましくないものであり、本明細書に
記載する、本発明の一部をなす演算はいずれも機械によ
る演算である。本発明の演算を行うに有用な機械として
は、汎用ディジタル・コンピュータや類似の装置があ
る。すべての場合において、コンピュータを操作するに
あたっての操作方法と、計算それ自体の方法との相違を
念頭においておくべきである。本発明は電気的またはそ
の他の（たとえば、機械的、化学的）物理信号を処理し
て、他の希望する物理信号を発生させるにあたってコン
ピュータを操作する方法のステップに関する。
の人間の操作員が行う知的な作業と一般的に関連づけら
れた用語で呼ばれることがしばしばある。このような人
間の操作員の能力はほとんどの場合必要のないものであ
ったり、あるいは望ましくないものであり、本明細書に
記載する、本発明の一部をなす演算はいずれも機械によ
る演算である。本発明の演算を行うに有用な機械として
は、汎用ディジタル・コンピュータや類似の装置があ
る。すべての場合において、コンピュータを操作するに
あたっての操作方法と、計算それ自体の方法との相違を
念頭においておくべきである。本発明は電気的またはそ
の他の（たとえば、機械的、化学的）物理信号を処理し
て、他の希望する物理信号を発生させるにあたってコン
ピュータを操作する方法のステップに関する。
【００１３】本発明はこれらの操作を行う装置にも関す
る。本装置は必要な目的に合わせて特に構成されたもの
であっても、あるいはコンピュータに記憶されているコ
ンピュータ・プログラムによって選択的に活動化あるい
は再構成される汎用コンピュータであってもよい。本明
細書で示す手順は本質的に、特定のコンピュータまたは
その他の装置に関するものではない。詳細にいえば、各
種の汎用機械を本発明の教示するところにしたがって作
成されたプログラムとともに使用してもよいし、また必
要な方法ステップを行うために専用装置を構成するのが
都合のよいこともある。各種のこれらの装置に必要な構
造は以下の説明から明らかとなろう。
る。本装置は必要な目的に合わせて特に構成されたもの
であっても、あるいはコンピュータに記憶されているコ
ンピュータ・プログラムによって選択的に活動化あるい
は再構成される汎用コンピュータであってもよい。本明
細書で示す手順は本質的に、特定のコンピュータまたは
その他の装置に関するものではない。詳細にいえば、各
種の汎用機械を本発明の教示するところにしたがって作
成されたプログラムとともに使用してもよいし、また必
要な方法ステップを行うために専用装置を構成するのが
都合のよいこともある。各種のこれらの装置に必要な構
造は以下の説明から明らかとなろう。
【００１４】実行時チェックのために動的パッチングを
行い、マルチスレッド・ターゲット・プログラムを迅速
にデバッグする装置および方法を開示する。以下の説明
において、本発明を完璧に理解させるため、特定の命令
呼出し、モジュールなどを記載する。しかしながら、当
分野の技術者には、本発明をこれらの特定の細部を用い
ることなく実施できることが明らかであろう。他の場合
には、周知の回路および装置をブロック図の形で示し、
本発明を不必要に煩雑としないようにした。同様に、好
ましい実施形態においては、ユニプロセッサ・コンピュ
ータ・システムおよびマルチプロセッサ・コンピュータ
・システム、ならびにＳｏｌａｒｉｓオペレーティング
・システムを使用しているが、これらはすべてＳｕｎ
Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．が製造販売してい
るものである。しかしながら、本発明は他のコンピュー
タ・ハードウェア・システム上で、かつ他の互換性のあ
るオペレーティング・システムを使用して実施できるも
のである。
行い、マルチスレッド・ターゲット・プログラムを迅速
にデバッグする装置および方法を開示する。以下の説明
において、本発明を完璧に理解させるため、特定の命令
呼出し、モジュールなどを記載する。しかしながら、当
分野の技術者には、本発明をこれらの特定の細部を用い
ることなく実施できることが明らかであろう。他の場合
には、周知の回路および装置をブロック図の形で示し、
本発明を不必要に煩雑としないようにした。同様に、好
ましい実施形態においては、ユニプロセッサ・コンピュ
ータ・システムおよびマルチプロセッサ・コンピュータ
・システム、ならびにＳｏｌａｒｉｓオペレーティング
・システムを使用しているが、これらはすべてＳｕｎ
Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．が製造販売してい
るものである。しかしながら、本発明は他のコンピュー
タ・ハードウェア・システム上で、かつ他の互換性のあ
るオペレーティング・システムを使用して実施できるも
のである。
【００１５】本発明は「マルチスレッド・アプリケーシ
ョン・プログラムに対する有効なメモリ・アクセスの実
行時チェック・デバッガ」（以下、「ＲＴＣ／ＭＴ」と
呼ぶ）のためのシステムおよび方法であり、シリアルま
たは並行のいずれかで作動する複数のスレッドを含んで
いる実行時プロセスをデバッガ・プログラムによって監
視し、かつメモリ・アクセス・エラーが、検出されてそ
のエラーに遭遇したプロセス・スレッドに正しく帰属さ
せられる。本願で説明する発明はWayne C.Gramlich,Sun
nyvale,CA.:Achut Reddy,San Jose,CA.:およびShyam De
sirazu,FosterCity,CA.による「Method and Apparatus f
or Run-Time Error Checking Using Dynamic Patching
」なる名称の１９９４年１月２８日出願の米国特許願
第０８／１８９，０８９号に記載されている実行時チェ
ック・システムに関し、またThomas Preisler,Wayne C.
Gramlich,Eduardo Pelegri LlopartおよびTerrence Mil
lerによる「Method and Apparatus for a Fast Debugge
r Fix & Continue Operation 」なる名称の１９９４年
９月１日出願の米国特許一部継続出願第０８／２９９，
７２０号に記載されているシステムに関するものであ
る。上記の出願は両者とも参照することによって、本明
細書の一部となる。上記の２件の出願（２件の出願の特
許）のうち最初のものはデバッグされるターゲット・ア
プリケーション・プログラムに関する実行時チェックを
開示し、特許を請求しており、第２の一部継続出願はさ
らにターゲット・アプリケーション・プログラムのエラ
ー修正および継続処理システムを開示し、特許を請求し
ている。親出願は動的パッチングを利用して、コンパイ
ラでは検出されないプログラム実行時のプログラム・エ
ラーを検出する。このような実行時エラーは、プログラ
ムに対応する実行時プロセスにパッチングを行い、プロ
グラムがメモリにアクセスしようとするあらゆる点にお
いて、プログラムがアクセスする代わりに、アクセスさ
れようとしているメモリ・アドレスに対するチェックが
行われるさまざまなロケーションに分岐するようにし
て、チェックされる。プログラムがアクセスしようとす
るメモリ・アドレスが無効な場合、エラーが記録され、
それ以外の場合、メモリ・アドレスが有効であれば、プ
ログラムは実行を継続する。実際のパッチング・プロセ
スはＲＴＣ内で行われる。デバッグ対象のターゲット・
プログラムがマルチスレッド・プログラムの場合、デバ
ッガが複数のスレッドが同時に実行されているかどうか
を追跡できるだけではなく、それ自体がそのルーチンの
複数アクセスを安全な態様で取り扱うことができるもの
でなければならないことが認識されよう。すなわち、Ｒ
ＴＣモジュールはマルチスレッドに対して安全な（「Ｍ
Ｔ安全」）ものでなければならない。ＲＴＣモジュール
がマルチスレッド・アプリケーション・プログラムのプ
ロセスをテストしている場合、ＲＴＣモジュールは他の
スレッドのスタックが存在しており、したがってこれら
の他のスタックのメモリ・ロケーションへのアクセスが
適正なアクセスであると認識しなければならず、したが
って、エラーに関する各チェックはすべてのスレッドの
活動についての知識に基づいて行わなければならず、ま
た検出された各エラーを、エラーが見つかった特定のス
レッドを参照して報告しなければならない。このような
マルチスレッド・エラー・チェック機能は、本願で特許
を請求する本発明の主題である。以下の説明で、好まし
い実施形態を、参照することによって本明細書の一部と
なり、かつ完全を期すため、以下である程度詳細に説明
する上述の親出願で詳細に説明されている実行時チェッ
クのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のシ
ングルスレッド・システムの改変形として説明する。実
行時チェックのマルチスレッド・バージョン（ＲＴＣ／
ＭＴ）はＣＰＵが１個または複数個のコンピュータ・ハ
ードウェアで作動するが、マルチスレッド・アプリケー
ションがマルチプロセッサ・システムで最も効果的に作
動するものであることは明らかである。したがって、以
下の説明には、マルチスレッド・プロセスを同時に実行
できる典型的なマルチプロセス構成の簡単な説明も含め
た。本発明がＩＢＭ、ヒューレット・パッカード、ＤＥ
Ｃ、ＭＩＰＳなど、どのようなベンダのマルチプロセッ
サ・システムで機能し、かつＩＢＭ、ヒューレット・パ
ッカード、ＤＥＣ、ＭＩＰＳ、マイクロソフト、ノベル
などのさまざまなソフトウェア・ベンダのデバッグ対象
アプリケーション・プログラムとともに作動するように
簡単になおすことができることが理解されよう。
ョン・プログラムに対する有効なメモリ・アクセスの実
行時チェック・デバッガ」（以下、「ＲＴＣ／ＭＴ」と
呼ぶ）のためのシステムおよび方法であり、シリアルま
たは並行のいずれかで作動する複数のスレッドを含んで
いる実行時プロセスをデバッガ・プログラムによって監
視し、かつメモリ・アクセス・エラーが、検出されてそ
のエラーに遭遇したプロセス・スレッドに正しく帰属さ
せられる。本願で説明する発明はWayne C.Gramlich,Sun
nyvale,CA.:Achut Reddy,San Jose,CA.:およびShyam De
sirazu,FosterCity,CA.による「Method and Apparatus f
or Run-Time Error Checking Using Dynamic Patching
」なる名称の１９９４年１月２８日出願の米国特許願
第０８／１８９，０８９号に記載されている実行時チェ
ック・システムに関し、またThomas Preisler,Wayne C.
Gramlich,Eduardo Pelegri LlopartおよびTerrence Mil
lerによる「Method and Apparatus for a Fast Debugge
r Fix & Continue Operation 」なる名称の１９９４年
９月１日出願の米国特許一部継続出願第０８／２９９，
７２０号に記載されているシステムに関するものであ
る。上記の出願は両者とも参照することによって、本明
細書の一部となる。上記の２件の出願（２件の出願の特
許）のうち最初のものはデバッグされるターゲット・ア
プリケーション・プログラムに関する実行時チェックを
開示し、特許を請求しており、第２の一部継続出願はさ
らにターゲット・アプリケーション・プログラムのエラ
ー修正および継続処理システムを開示し、特許を請求し
ている。親出願は動的パッチングを利用して、コンパイ
ラでは検出されないプログラム実行時のプログラム・エ
ラーを検出する。このような実行時エラーは、プログラ
ムに対応する実行時プロセスにパッチングを行い、プロ
グラムがメモリにアクセスしようとするあらゆる点にお
いて、プログラムがアクセスする代わりに、アクセスさ
れようとしているメモリ・アドレスに対するチェックが
行われるさまざまなロケーションに分岐するようにし
て、チェックされる。プログラムがアクセスしようとす
るメモリ・アドレスが無効な場合、エラーが記録され、
それ以外の場合、メモリ・アドレスが有効であれば、プ
ログラムは実行を継続する。実際のパッチング・プロセ
スはＲＴＣ内で行われる。デバッグ対象のターゲット・
プログラムがマルチスレッド・プログラムの場合、デバ
ッガが複数のスレッドが同時に実行されているかどうか
を追跡できるだけではなく、それ自体がそのルーチンの
複数アクセスを安全な態様で取り扱うことができるもの
でなければならないことが認識されよう。すなわち、Ｒ
ＴＣモジュールはマルチスレッドに対して安全な（「Ｍ
Ｔ安全」）ものでなければならない。ＲＴＣモジュール
がマルチスレッド・アプリケーション・プログラムのプ
ロセスをテストしている場合、ＲＴＣモジュールは他の
スレッドのスタックが存在しており、したがってこれら
の他のスタックのメモリ・ロケーションへのアクセスが
適正なアクセスであると認識しなければならず、したが
って、エラーに関する各チェックはすべてのスレッドの
活動についての知識に基づいて行わなければならず、ま
た検出された各エラーを、エラーが見つかった特定のス
レッドを参照して報告しなければならない。このような
マルチスレッド・エラー・チェック機能は、本願で特許
を請求する本発明の主題である。以下の説明で、好まし
い実施形態を、参照することによって本明細書の一部と
なり、かつ完全を期すため、以下である程度詳細に説明
する上述の親出願で詳細に説明されている実行時チェッ
クのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のシ
ングルスレッド・システムの改変形として説明する。実
行時チェックのマルチスレッド・バージョン（ＲＴＣ／
ＭＴ）はＣＰＵが１個または複数個のコンピュータ・ハ
ードウェアで作動するが、マルチスレッド・アプリケー
ションがマルチプロセッサ・システムで最も効果的に作
動するものであることは明らかである。したがって、以
下の説明には、マルチスレッド・プロセスを同時に実行
できる典型的なマルチプロセス構成の簡単な説明も含め
た。本発明がＩＢＭ、ヒューレット・パッカード、ＤＥ
Ｃ、ＭＩＰＳなど、どのようなベンダのマルチプロセッ
サ・システムで機能し、かつＩＢＭ、ヒューレット・パ
ッカード、ＤＥＣ、ＭＩＰＳ、マイクロソフト、ノベル
などのさまざまなソフトウェア・ベンダのデバッグ対象
アプリケーション・プログラムとともに作動するように
簡単になおすことができることが理解されよう。
【００１６】図１は動的パッチングを使用する実行時エ
ラー・チェックを備えたコンピュータ・システムのシス
テム・ブロック図である。図１に示すコンピュータ・シ
ステムが概念的な形で示されており、コンピュータ・シ
ステムの多くの付加的な回路、装置、および相互接続が
本発明を煩雑としないために示されていないことが理解
されよう。
ラー・チェックを備えたコンピュータ・システムのシス
テム・ブロック図である。図１に示すコンピュータ・シ
ステムが概念的な形で示されており、コンピュータ・シ
ステムの多くの付加的な回路、装置、および相互接続が
本発明を煩雑としないために示されていないことが理解
されよう。
【００１７】シングルスレッドＲＴＣシステム図１はシ
ングルスレッドＲＴＣシステムを示す。図１に示すよう
に、ターゲット・プログラムのイメージが入出力装置３
０４によってデバッガ・プログラム３０７（ｄｂｘ）に
読み込まれ、メモリに記憶されて、プログラム３０２の
メモリ内コピー３０８をもたらす。「実行時チェック」
（ＲＴＣ）モジュール３０９と呼ばれるデバッガ・プロ
グラム３０７内のモジュールはユーザ・インタフェース
を操作して、エラー・メッセージを印刷し、またプログ
ラム３０２に対応するメモリ内プロセス３０８のパッチ
ングを処理する。共用ライブラリ（ライブラリ）モジュ
ール３１０がコンピュータのメモリ３０５にロードさ
れ、実行時チェックを行う。好ましい実施形態におい
て、使用される主ライブラリ・ルーチンは「librtc.so
」で示されている。
ングルスレッドＲＴＣシステムを示す。図１に示すよう
に、ターゲット・プログラムのイメージが入出力装置３
０４によってデバッガ・プログラム３０７（ｄｂｘ）に
読み込まれ、メモリに記憶されて、プログラム３０２の
メモリ内コピー３０８をもたらす。「実行時チェック」
（ＲＴＣ）モジュール３０９と呼ばれるデバッガ・プロ
グラム３０７内のモジュールはユーザ・インタフェース
を操作して、エラー・メッセージを印刷し、またプログ
ラム３０２に対応するメモリ内プロセス３０８のパッチ
ングを処理する。共用ライブラリ（ライブラリ）モジュ
ール３１０がコンピュータのメモリ３０５にロードさ
れ、実行時チェックを行う。好ましい実施形態におい
て、使用される主ライブラリ・ルーチンは「librtc.so
」で示されている。
【００１８】プログラム（プロセス）３０８のこのメモ
リ内コピーは、本明細書で「計装プログラム」と呼ばれ
るパッチングされたプロセスとなる。パッチングはター
ゲット・プログラムのこのメモリ内コピー３０８だけに
適用され、ディスク３０１に格納されている元のプログ
ラム３０２には適用されない。したがって、元のファイ
ル３０２が変更されることはなく、また実行可能プログ
ラムに対して必要なファイルの再リンクは行われない。
さらに、プログラム３０２に事前にパッチングする必要
はない。その代わり、パッチングはチェックが開始され
たときに行われる。したがって、ユーザによる選択は実
行前ではなく、実際の実行時まで遅らされる。ＣＰＵ３
０６はデバッガ３０７およびテスト対象プログラム３０
８のプログラム実行を制御する。ＣＰＵ３０６はプログ
ラム・カウンタ（「ＰＣ」）３１２を含んでおり、これ
は実行される次の命令をポイントしている。
リ内コピーは、本明細書で「計装プログラム」と呼ばれ
るパッチングされたプロセスとなる。パッチングはター
ゲット・プログラムのこのメモリ内コピー３０８だけに
適用され、ディスク３０１に格納されている元のプログ
ラム３０２には適用されない。したがって、元のファイ
ル３０２が変更されることはなく、また実行可能プログ
ラムに対して必要なファイルの再リンクは行われない。
さらに、プログラム３０２に事前にパッチングする必要
はない。その代わり、パッチングはチェックが開始され
たときに行われる。したがって、ユーザによる選択は実
行前ではなく、実際の実行時まで遅らされる。ＣＰＵ３
０６はデバッガ３０７およびテスト対象プログラム３０
８のプログラム実行を制御する。ＣＰＵ３０６はプログ
ラム・カウンタ（「ＰＣ」）３１２を含んでおり、これ
は実行される次の命令をポイントしている。
【００１９】Ｓｕｎ ｄｂｘデバッガ・プログラム３０
７はリンク時に指定されていなかったライブラリを実行
時に動的にロードすることができる。ライブラリのこの
ようなローディングがデバッガ・プログラム３０７内で
動的に行われるため、ＲＴＣモジュール３０９は新しい
ライブラリをプログラムにロードするすべての呼出しを
トラップすることができ、このようなライブラリが実行
される直前にパッチングを適用することができる。
７はリンク時に指定されていなかったライブラリを実行
時に動的にロードすることができる。ライブラリのこの
ようなローディングがデバッガ・プログラム３０７内で
動的に行われるため、ＲＴＣモジュール３０９は新しい
ライブラリをプログラムにロードするすべての呼出しを
トラップすることができ、このようなライブラリが実行
される直前にパッチングを適用することができる。
【００２０】要約すると、Ｓｕｎ ｄｂｘデバッガの場
合、実行前のプログラムの事前パッチングは必要ない。
その代わり、パッチングはチェックが開始されたときに
適用され、これによってユーザの選択の実際の実行時ま
で遅らせる。さらに、ターゲット・プログラムのオブジ
ェクト・コードをまったく変更せず、それ故、実行可能
プログラムを作成するためにオブジェクト・ファイルを
再リンクする必要をなくすることによって、本方法の手
法は余分なリンクを使用することを防止する。最後に、
パッチングは完全に計装されたプロセスが達成されるよ
うに、既存のターゲット・プログラムによって開始され
るメモリ内プロセスに適用される。
合、実行前のプログラムの事前パッチングは必要ない。
その代わり、パッチングはチェックが開始されたときに
適用され、これによってユーザの選択の実際の実行時ま
で遅らせる。さらに、ターゲット・プログラムのオブジ
ェクト・コードをまったく変更せず、それ故、実行可能
プログラムを作成するためにオブジェクト・ファイルを
再リンクする必要をなくすることによって、本方法の手
法は余分なリンクを使用することを防止する。最後に、
パッチングは完全に計装されたプロセスが達成されるよ
うに、既存のターゲット・プログラムによって開始され
るメモリ内プロセスに適用される。
【００２１】ここで図２を参照すると、Ｓｕｎ ｄｂｘ
デバッガの実行時チェック（以下、「ＲＴＣ」とする）
に対する動的パッチング方法の総括的な流れ図が示され
ている。メモリ・アクセス・エラーを検出するために、
スタックに対するアクセスおよびユーザ・メモリにアク
セスするシステム・コールを含むすべてのメモリ・アク
セス命令がインターセプトされる。このようなメモリ・
アクセス命令をアクセスされるメモリ・アドレスの妥当
性に関して検証してから、命令の実行を継続する。
デバッガの実行時チェック（以下、「ＲＴＣ」とする）
に対する動的パッチング方法の総括的な流れ図が示され
ている。メモリ・アクセス・エラーを検出するために、
スタックに対するアクセスおよびユーザ・メモリにアク
セスするシステム・コールを含むすべてのメモリ・アク
セス命令がインターセプトされる。このようなメモリ・
アクセス命令をアクセスされるメモリ・アドレスの妥当
性に関して検証してから、命令の実行を継続する。
【００２２】このようなエラー・チェックのために、Ｒ
ＴＣはチェックされる関数を、パッチングを必要とする
メモリ・アクセス命令のロケーションについて走査（探
索）する。次に、パッチングが必要なロケーションが、
パッチング・サイトとして特定される。さらに、これら
のパッチング・サイトにおける元の命令はパッチング領
域への分岐と置き換えられる。
ＴＣはチェックされる関数を、パッチングを必要とする
メモリ・アクセス命令のロケーションについて走査（探
索）する。次に、パッチングが必要なロケーションが、
パッチング・サイトとして特定される。さらに、これら
のパッチング・サイトにおける元の命令はパッチング領
域への分岐と置き換えられる。
【００２３】図２、ブロック１００に示すように、パッ
チング・テーブル用にスペースが割り当てられ、パッチ
ング・テーブルと値が初期化される。次に、ブロック１
１０に示すように、エラー・チェック対象プログラムを
まず読み取り、これがディスク・ファイル上に存在する
場合には、ロードする。このようなプログラムは通常、
ユーザがこれらにアクセスしたときに、部分的にロード
される（ロード・オブジェクト）。しかしながら、図２
に示すステップを行うことによって、デバッガは本質的
にすべてのプログラムがアクセスされるようにする。し
たがって、結果として、デバッガ・プログラムがそのプ
ロセスを完了したときに、プログラムのすべてにパッチ
ングが行われることとなる。このデバッガ・プログラム
は他のプロセスを読み書きできる特別なプロセスであ
り、したがって、メモリ内にあるプログラム・イメージ
・プロセスを変更することができる。図２内に示したす
べての操作はデバッガ・プログラム内のＲＴＣモジュー
ルによって行われる。図２、ブロック１３０から明らか
なように、デバッガ・プログラムはロード・オブジェク
トのリストを作成する。ロード・オブジェクトはプログ
ラム内のセグメント／関数を含んでおり、これらはメモ
リ・アクセス命令を有している。プログラムは多数のこ
れらのロード・オブジェクトからなっていてもよい。第
１のタイプのロード・オブジェクトはプログラムの主ル
ーチンで、これはプログラムのユーザ部分である。プロ
グラムが使用する共用ライブラリもあり、これは他のタ
イプのロード・オブジェクトである。両方のタイプのロ
ード・オブジェクトがプログラムの実行には必要であ
る。デバッガ・プログラムはロード・オブジェクトのリ
ストを受け取ると、ロード・オブジェクトを走査して、
後でパッチングを行う命令を探索する。この命令ごとの
走査の際にデバッガ・プログラムが調べるロード・オブ
ジェクトの部分は命令自体、すなわちテキストだけであ
り、データではない。
チング・テーブル用にスペースが割り当てられ、パッチ
ング・テーブルと値が初期化される。次に、ブロック１
１０に示すように、エラー・チェック対象プログラムを
まず読み取り、これがディスク・ファイル上に存在する
場合には、ロードする。このようなプログラムは通常、
ユーザがこれらにアクセスしたときに、部分的にロード
される（ロード・オブジェクト）。しかしながら、図２
に示すステップを行うことによって、デバッガは本質的
にすべてのプログラムがアクセスされるようにする。し
たがって、結果として、デバッガ・プログラムがそのプ
ロセスを完了したときに、プログラムのすべてにパッチ
ングが行われることとなる。このデバッガ・プログラム
は他のプロセスを読み書きできる特別なプロセスであ
り、したがって、メモリ内にあるプログラム・イメージ
・プロセスを変更することができる。図２内に示したす
べての操作はデバッガ・プログラム内のＲＴＣモジュー
ルによって行われる。図２、ブロック１３０から明らか
なように、デバッガ・プログラムはロード・オブジェク
トのリストを作成する。ロード・オブジェクトはプログ
ラム内のセグメント／関数を含んでおり、これらはメモ
リ・アクセス命令を有している。プログラムは多数のこ
れらのロード・オブジェクトからなっていてもよい。第
１のタイプのロード・オブジェクトはプログラムの主ル
ーチンで、これはプログラムのユーザ部分である。プロ
グラムが使用する共用ライブラリもあり、これは他のタ
イプのロード・オブジェクトである。両方のタイプのロ
ード・オブジェクトがプログラムの実行には必要であ
る。デバッガ・プログラムはロード・オブジェクトのリ
ストを受け取ると、ロード・オブジェクトを走査して、
後でパッチングを行う命令を探索する。この命令ごとの
走査の際にデバッガ・プログラムが調べるロード・オブ
ジェクトの部分は命令自体、すなわちテキストだけであ
り、データではない。
【００２４】デバッガ・プログラムはパッチング・サイ
トを特定するとともに、パッチング・サイト・アドレ
ス、パッチング領域アドレス、パッチング・タイプ（す
なわち、メモリ・アクセス命令のタイプ）、特定のパッ
チング・サイトにパッチングを行うべきかどうか、およ
びアクセスされるメモリのサイズを含む、パッチング・
サイトに関する情報の蓄積も行う。すべてのロード・オ
ブジェクトは上記のパッチング・サイト情報のテーブル
を有しており、テーブルの１つの項目が各パッチング・
サイトとなる。パッチング・タイプすなわちパッチング
のためのメモリ・アクセス命令のタイプは、エラー・チ
ェックが処理されるパッチング領域の対応するセクショ
ンのサイズを定義する。特定のパッチング・サイトに対
してユーザが発行するチェック・コマンドまたは非チェ
ック・コマンドはその特定のパッチング・サイトに対し
てエラーを報告するか否かを示すものとなる。詳細にい
えば、チェック・コマンドは特定のパッチング・サイト
がエラーを報告すべきことを示し、非チェック・コマン
ドは逆に、その特定のパッチング・サイトに関するエラ
ーを報告すべきではないことを示す。走査の最終時に、
デバッガ・プログラムは発見したパッチング・サイトを
収容するためにデバッガ・プログラムが必要となるパッ
チング領域セクションの総サイズを示す。パッチング・
サイトの特定はロード・オブジェクトあたり１回必要な
だけであり、それ以降の実行パスではパッチング領域ス
ペースの対応するセクションに対するスペースを見つけ
だし、パッチングをインストールすることだけが必要と
なる。パッチング領域セクションに必要な総サイズが記
録され、パッチング領域セクションのサイズのリストが
作成される。パッチング領域セクションのサイズのこの
リストは次のステップ、すなわちステップ１４０に入力
され、メモリ・スペースがパッチング領域に実際に割り
当てられる。ステップ１４０において、デバッガ・プロ
グラムはパッチング領域セクションのサイズのリストを
取り入れ、スペースをこれらに割り当てろうと試みる。
デバッガ・プログラムはまずアドレス・スペースの初期
マップを作成し、あらゆるものがどこにレイアウトされ
ているのかを調べる。システムはメモリ内のさまざまな
場所にあるロード・オブジェクトをマップする。ロード
・オブジェクトのこのようなマッピングは必ずしも連続
している必要はなく、アドレス・スペースにはホールが
ある。デバッガ・プログラムのジョブはこれらのホール
を特定し、これらのホールに必要なスペースに対する要
求のリストをマップすることである。
トを特定するとともに、パッチング・サイト・アドレ
ス、パッチング領域アドレス、パッチング・タイプ（す
なわち、メモリ・アクセス命令のタイプ）、特定のパッ
チング・サイトにパッチングを行うべきかどうか、およ
びアクセスされるメモリのサイズを含む、パッチング・
サイトに関する情報の蓄積も行う。すべてのロード・オ
ブジェクトは上記のパッチング・サイト情報のテーブル
を有しており、テーブルの１つの項目が各パッチング・
サイトとなる。パッチング・タイプすなわちパッチング
のためのメモリ・アクセス命令のタイプは、エラー・チ
ェックが処理されるパッチング領域の対応するセクショ
ンのサイズを定義する。特定のパッチング・サイトに対
してユーザが発行するチェック・コマンドまたは非チェ
ック・コマンドはその特定のパッチング・サイトに対し
てエラーを報告するか否かを示すものとなる。詳細にい
えば、チェック・コマンドは特定のパッチング・サイト
がエラーを報告すべきことを示し、非チェック・コマン
ドは逆に、その特定のパッチング・サイトに関するエラ
ーを報告すべきではないことを示す。走査の最終時に、
デバッガ・プログラムは発見したパッチング・サイトを
収容するためにデバッガ・プログラムが必要となるパッ
チング領域セクションの総サイズを示す。パッチング・
サイトの特定はロード・オブジェクトあたり１回必要な
だけであり、それ以降の実行パスではパッチング領域ス
ペースの対応するセクションに対するスペースを見つけ
だし、パッチングをインストールすることだけが必要と
なる。パッチング領域セクションに必要な総サイズが記
録され、パッチング領域セクションのサイズのリストが
作成される。パッチング領域セクションのサイズのこの
リストは次のステップ、すなわちステップ１４０に入力
され、メモリ・スペースがパッチング領域に実際に割り
当てられる。ステップ１４０において、デバッガ・プロ
グラムはパッチング領域セクションのサイズのリストを
取り入れ、スペースをこれらに割り当てろうと試みる。
デバッガ・プログラムはまずアドレス・スペースの初期
マップを作成し、あらゆるものがどこにレイアウトされ
ているのかを調べる。システムはメモリ内のさまざまな
場所にあるロード・オブジェクトをマップする。ロード
・オブジェクトのこのようなマッピングは必ずしも連続
している必要はなく、アドレス・スペースにはホールが
ある。デバッガ・プログラムのジョブはこれらのホール
を特定し、これらのホールに必要なスペースに対する要
求のリストをマップすることである。
【００２５】Ｓｕｎ ｄｂｘデバッガＲＴＣプログラム
の一実施形態においては、アドレス・スペース・データ
にアクセスして、アドレス・スペースのすべてのセグメ
ントのリストを、各セグメントの開始アドレスおよびサ
イズとともに取得する。これらのセグメントはテキス
ト、データ、スタックおよび（または）ヒープのセグメ
ントからなっていてもよい。本明細書で「ホール」と呼
ぶこのようなセグメントの間のスペースは、パッチング
領域セクションに対してスペースを割り当てるために使
用される。各テキスト・セグメントの開始アドレス、各
テキスト・セグメントの終了アドレス、およびパッチン
グ領域セクションのサイズを含んでおり、各テキスト・
セグメントの開始アドレスの昇順で記憶されるリスト
が、以前のステップ１３０から得られる。ステップ１４
０において、各ホールの開始アドレスでソートされて記
憶される、ホールの開始アドレスおよびセグメントサイ
ズの入ったホールのリストが生成される。パッチング領
域の対応するセクションに対するパッチング・サイトよ
りもアドレス・ロケーションが高いホールをまずチェッ
クすることによって、上述のホールを必要なパッチング
領域セクションのサイズと比較する。スペースが割り当
てられるパッチング領域セクションのサイズよりもサイ
ズが大きいホールが与えられ、そのホールがスタック・
セグメントの直前にない場合には、パッチング領域セク
ションにはホール・スペースが割り当てられる。パッチ
ング領域セクションのサイズのリスト、およびホールの
リストを終わり、ホールをパッチング領域セクションに
割り当てった後、作成された未割当てパッチング領域セ
クションのリストが降順で走査される。パッチング領域
の対応するセクションと等しいか、これよりも大きいパ
ッチング・サイトよりも低いアドレスにあるホールが探
索される。パッチング領域の特定のセクションと等しい
か、これよりも大きいホールはパッチング領域のそのセ
クションに割り当てられる。パッチング領域のこのよう
なセクションはホールの一番下におかれる。パッチング
領域の対応するセクションがこのステップの最後で割り
当てられていないパッチング・サイトにはパッチングが
行われず、ユーザには、エラー・チェックの要求が満た
されなかったという警告が与えられる。ステップ１５０
において、システムはパッチング領域のすべてのセクシ
ョンがどこにあるのかについての情報を取り入れ、その
情報をパッチング・テーブルに格納し、これらのパッチ
ング・テーブルのアドレス情報を更新する。
の一実施形態においては、アドレス・スペース・データ
にアクセスして、アドレス・スペースのすべてのセグメ
ントのリストを、各セグメントの開始アドレスおよびサ
イズとともに取得する。これらのセグメントはテキス
ト、データ、スタックおよび（または）ヒープのセグメ
ントからなっていてもよい。本明細書で「ホール」と呼
ぶこのようなセグメントの間のスペースは、パッチング
領域セクションに対してスペースを割り当てるために使
用される。各テキスト・セグメントの開始アドレス、各
テキスト・セグメントの終了アドレス、およびパッチン
グ領域セクションのサイズを含んでおり、各テキスト・
セグメントの開始アドレスの昇順で記憶されるリスト
が、以前のステップ１３０から得られる。ステップ１４
０において、各ホールの開始アドレスでソートされて記
憶される、ホールの開始アドレスおよびセグメントサイ
ズの入ったホールのリストが生成される。パッチング領
域の対応するセクションに対するパッチング・サイトよ
りもアドレス・ロケーションが高いホールをまずチェッ
クすることによって、上述のホールを必要なパッチング
領域セクションのサイズと比較する。スペースが割り当
てられるパッチング領域セクションのサイズよりもサイ
ズが大きいホールが与えられ、そのホールがスタック・
セグメントの直前にない場合には、パッチング領域セク
ションにはホール・スペースが割り当てられる。パッチ
ング領域セクションのサイズのリスト、およびホールの
リストを終わり、ホールをパッチング領域セクションに
割り当てった後、作成された未割当てパッチング領域セ
クションのリストが降順で走査される。パッチング領域
の対応するセクションと等しいか、これよりも大きいパ
ッチング・サイトよりも低いアドレスにあるホールが探
索される。パッチング領域の特定のセクションと等しい
か、これよりも大きいホールはパッチング領域のそのセ
クションに割り当てられる。パッチング領域のこのよう
なセクションはホールの一番下におかれる。パッチング
領域の対応するセクションがこのステップの最後で割り
当てられていないパッチング・サイトにはパッチングが
行われず、ユーザには、エラー・チェックの要求が満た
されなかったという警告が与えられる。ステップ１５０
において、システムはパッチング領域のすべてのセクシ
ョンがどこにあるのかについての情報を取り入れ、その
情報をパッチング・テーブルに格納し、これらのパッチ
ング・テーブルのアドレス情報を更新する。
【００２６】ステップ１６０において、パッチング領域
セクションに対するスペースが割り当てられ、パッチン
グを行う必要のある元のターゲット・プログラムのすべ
ての命令が特定される。この段階でパッチングが実際に
書き出され、この段階の完了時に、プログラムは完全に
計装されたプロセスに変換される。上述したようなパッ
チング・サイト情報を含んでいる（すなわち、パッチン
グ・サイト・アドレス、パッチング領域アドレス、パッ
チング・タイプ、パッチング・サイトにパッチングを行
うかどうか、および参照されるメモリのサイズを含んで
いる）データのテーブルを使用してパッチング・サイト
を決定する。パッチング・サイトとパッチング領域の対
応するセクションとを含んでいるページが読み取られな
かった場合には、これらを読み取り、パッチング・タイ
プをパッチング領域の対応するセクションに書き出す。
パッチング・サイトにある元の命令はパッチング領域の
対応するセクションへの分岐命令で置き換えられ、この
ような変位された命令はパッチング領域の対応するセク
ションにおかれる。このパッチングは非チェック・コマ
ンドがこの特定のパッチング・サイトに対して発行され
たかどうかにかかわりなく行われる。一方、非チェック
・コマンドがこの特定のパッチング・サイトに対して発
行された場合には、パッチングは他のすべてのロケーシ
ョンに対して完了するが、このロケーションに対しては
検出される可能性のあるエラーを無視するフラグがセッ
トされる。
セクションに対するスペースが割り当てられ、パッチン
グを行う必要のある元のターゲット・プログラムのすべ
ての命令が特定される。この段階でパッチングが実際に
書き出され、この段階の完了時に、プログラムは完全に
計装されたプロセスに変換される。上述したようなパッ
チング・サイト情報を含んでいる（すなわち、パッチン
グ・サイト・アドレス、パッチング領域アドレス、パッ
チング・タイプ、パッチング・サイトにパッチングを行
うかどうか、および参照されるメモリのサイズを含んで
いる）データのテーブルを使用してパッチング・サイト
を決定する。パッチング・サイトとパッチング領域の対
応するセクションとを含んでいるページが読み取られな
かった場合には、これらを読み取り、パッチング・タイ
プをパッチング領域の対応するセクションに書き出す。
パッチング・サイトにある元の命令はパッチング領域の
対応するセクションへの分岐命令で置き換えられ、この
ような変位された命令はパッチング領域の対応するセク
ションにおかれる。このパッチングは非チェック・コマ
ンドがこの特定のパッチング・サイトに対して発行され
たかどうかにかかわりなく行われる。一方、非チェック
・コマンドがこの特定のパッチング・サイトに対して発
行された場合には、パッチングは他のすべてのロケーシ
ョンに対して完了するが、このロケーションに対しては
検出される可能性のあるエラーを無視するフラグがセッ
トされる。
【００２７】ロード・オブジェクトのパッチング中、一
切の割り込みはブロックされ、ロード・オブジェクトの
パッチング間のサービスはブロック解除されて、ロード
・オブジェクトに正しくパッチングが行われるか、ある
いはまったく行われないかのいずれかとなるようにす
る。プログラムが活動状態にあるときにユーザがチェッ
ク・コマンドを発行すると、その時点でスタック上で活
動状態のロード・オブジェクトのパッチングは行えなく
なる。しかしながら、プログラムが活動状態の間に発行
された非チェック・コマンドは、このロケーションに対
して「do not report the error 」フラグをセットさせ
る。このステップはプロセスを実行しようというときに
そのプロセスで実施された初期パッチングを完了する。
切の割り込みはブロックされ、ロード・オブジェクトの
パッチング間のサービスはブロック解除されて、ロード
・オブジェクトに正しくパッチングが行われるか、ある
いはまったく行われないかのいずれかとなるようにす
る。プログラムが活動状態にあるときにユーザがチェッ
ク・コマンドを発行すると、その時点でスタック上で活
動状態のロード・オブジェクトのパッチングは行えなく
なる。しかしながら、プログラムが活動状態の間に発行
された非チェック・コマンドは、このロケーションに対
して「do not report the error 」フラグをセットさせ
る。このステップはプロセスを実行しようというときに
そのプロセスで実施された初期パッチングを完了する。
【００２８】本質的に、図２に示したステップ１００な
いし１６０というすべてのステップは、ユーザがデバッ
ガ・プログラム内でターゲット・プログラムを作動させ
ようと（プロセスを実行しようと）望んだときに行われ
る。要約すると、ステップ１００ないし１６０はプログ
ラムを起動したときに存在しているすべてのロード・オ
ブジェクトに対するパッチングを完了する。
いし１６０というすべてのステップは、ユーザがデバッ
ガ・プログラム内でターゲット・プログラムを作動させ
ようと（プロセスを実行しようと）望んだときに行われ
る。要約すると、ステップ１００ないし１６０はプログ
ラムを起動したときに存在しているすべてのロード・オ
ブジェクトに対するパッチングを完了する。
【００２９】さらに、デバッガ・プログラムはプログラ
ムを起動したときにプログラム内になかった新しいロー
ド・オブジェクトを動的にロードすることができる。シ
ステムは新しいロード・オブジェクトに対するすべての
呼出しをトラップし、プログラムが新しいオブジェクト
をロードしようとしているとデバッガ・プログラムが判
断したとき、デバッガ・プログラムは同じようなステッ
プのセットを行う。ステップ１１０、１２０、２００、
１４０、１５０、１６０および１７０は新しいロード・
オブジェクトの動的ローディングを示している。これら
のステップは初期化がないことを除けば、以前に行った
ステップと同じものである。大域初期化は１回だけ行わ
れ、その後、これらのステップは動的にロードされる各
新しいロード・オブジェクトに対して行われる。
ムを起動したときにプログラム内になかった新しいロー
ド・オブジェクトを動的にロードすることができる。シ
ステムは新しいロード・オブジェクトに対するすべての
呼出しをトラップし、プログラムが新しいオブジェクト
をロードしようとしているとデバッガ・プログラムが判
断したとき、デバッガ・プログラムは同じようなステッ
プのセットを行う。ステップ１１０、１２０、２００、
１４０、１５０、１６０および１７０は新しいロード・
オブジェクトの動的ローディングを示している。これら
のステップは初期化がないことを除けば、以前に行った
ステップと同じものである。大域初期化は１回だけ行わ
れ、その後、これらのステップは動的にロードされる各
新しいロード・オブジェクトに対して行われる。
【００３０】ステップ１７５、１８０および１８５に示
すように、デバッガ・プログラムはパッチングのインス
トールを解除し、ロード・オブジェクトを動的にアンロ
ードすることもできる。インストール解除コマンドを受
け取った場合、ステップ１７５、１８０および１８５が
行われる。ステップ１７５において、パッチングされる
関数が与えられた場合、インストール解除対象パッチン
グ・サイトを含んでいるページ、ならびにパッチング領
域の対応するセクションを含んでいるページが読み取ら
れる。次いで、元の命令がパッチング領域のセクション
から取得され、パッチング・サイトのパッチング領域へ
の分岐命令がこの元の命令に置き換えられる。パッチン
グ・サイトのパッチング命令の置き換えに加えて、これ
らのパッチング・サイトにおけるユーザ・ブレークポイ
ントはパッチング・サイトと関連するブレークポイント
・データ構造におけるパッチング命令の置き換えも必要
とする。パッチング・サイトにパッチングが行われなか
った場合、ユーザに対して警告が出され、何もインスト
ール解除されない。チェック・コマンドを発行したユー
ザはパッチング・サイトにある命令をパッチング領域へ
の分岐命令と置き換えるだけである。
すように、デバッガ・プログラムはパッチングのインス
トールを解除し、ロード・オブジェクトを動的にアンロ
ードすることもできる。インストール解除コマンドを受
け取った場合、ステップ１７５、１８０および１８５が
行われる。ステップ１７５において、パッチングされる
関数が与えられた場合、インストール解除対象パッチン
グ・サイトを含んでいるページ、ならびにパッチング領
域の対応するセクションを含んでいるページが読み取ら
れる。次いで、元の命令がパッチング領域のセクション
から取得され、パッチング・サイトのパッチング領域へ
の分岐命令がこの元の命令に置き換えられる。パッチン
グ・サイトのパッチング命令の置き換えに加えて、これ
らのパッチング・サイトにおけるユーザ・ブレークポイ
ントはパッチング・サイトと関連するブレークポイント
・データ構造におけるパッチング命令の置き換えも必要
とする。パッチング・サイトにパッチングが行われなか
った場合、ユーザに対して警告が出され、何もインスト
ール解除されない。チェック・コマンドを発行したユー
ザはパッチング・サイトにある命令をパッチング領域へ
の分岐命令と置き換えるだけである。
【００３１】ステップ１８０において、プログラマの任
意選択で、ロード・オブジェクトに割り当てられたスペ
ースを割当て解除することができる。動的割当て解除は
アドレス・スペースを節約するために行われる。多数の
新しいロード・オブジェクトをロードしようという場
合、空のアドレス・スペースがないことがある。もはや
必要なくなったモジュールがある場合、このようなスペ
ースを使用する可能性に備えて割当て解除するのが有利
なことがある。最後に、ステップ１９０において、パッ
チング・テーブルがパッチング領域の割当て解除された
セクションに関する情報によって更新される。
意選択で、ロード・オブジェクトに割り当てられたスペ
ースを割当て解除することができる。動的割当て解除は
アドレス・スペースを節約するために行われる。多数の
新しいロード・オブジェクトをロードしようという場
合、空のアドレス・スペースがないことがある。もはや
必要なくなったモジュールがある場合、このようなスペ
ースを使用する可能性に備えて割当て解除するのが有利
なことがある。最後に、ステップ１９０において、パッ
チング・テーブルがパッチング領域の割当て解除された
セクションに関する情報によって更新される。
【００３２】上述のように、このパッチング操作はプロ
セスがマルチスレッド・モードで実行されるのか、シン
グルスレッド・モードで実行されるのかにかかわりなく
同じである。ターゲット・プロセスがマルチスレッド・
プロセスとして実行される場合、異なるライブラリ・モ
ジュール（たとえば、libthread ）が呼び出される。
セスがマルチスレッド・モードで実行されるのか、シン
グルスレッド・モードで実行されるのかにかかわりなく
同じである。ターゲット・プロセスがマルチスレッド・
プロセスとして実行される場合、異なるライブラリ・モ
ジュール（たとえば、libthread ）が呼び出される。
【００３３】図３はＳｕｎ ｄｂｘデバッガで使用され
る実行時エラー・チェック方法の動的パッチングを示
す。ターゲット・プログラムは多数のロード・オブジェ
クトからなっており、ロード・オブジェクトは多数の関
数を含んでいる。関数ｆｏｏとしての関数１０はその一
例である。このような関数は多数のメモリ・アクセス関
連命令を有している。このような命令の１つをロード命
令４０として示す。実行時チェック（ＲＴＣ）モジュー
ルはこれがパッチングを行うすべてのロード・オブジェ
クトに対するこのような命令のすべてにパッチングを行
う。この実行時チェック（ＲＴＣ）モジュールは図２の
枠１３０で示すように、パッチングを行う必要のあるす
べての個別の命令を走査し、元の命令はパッチング領域
への無条件分岐命令によって置き換えられる。パッチン
グの行われる命令のロケーションを「パッチング・サイ
ト」２０と呼ぶ。したがって、ロード・オブジェクト内
のあるロケーションにロード命令がある場合、そのロケ
ーションは「パッチング・サイト」２０と呼ばれること
となる。エラー・チェックが行われるメモリ・ロケーシ
ョンは「パッチング領域」５０と呼ばれる。各パッチン
グ領域５０に対して、パッチング領域６０の１つまたは
複数のセクションがあり、各セクションは一意のパッチ
ング・サイトに対応している。したがって、１０００の
パッチング・サイトがある場合、パッチング領域のセク
ションは１０００あることになる。
る実行時エラー・チェック方法の動的パッチングを示
す。ターゲット・プログラムは多数のロード・オブジェ
クトからなっており、ロード・オブジェクトは多数の関
数を含んでいる。関数ｆｏｏとしての関数１０はその一
例である。このような関数は多数のメモリ・アクセス関
連命令を有している。このような命令の１つをロード命
令４０として示す。実行時チェック（ＲＴＣ）モジュー
ルはこれがパッチングを行うすべてのロード・オブジェ
クトに対するこのような命令のすべてにパッチングを行
う。この実行時チェック（ＲＴＣ）モジュールは図２の
枠１３０で示すように、パッチングを行う必要のあるす
べての個別の命令を走査し、元の命令はパッチング領域
への無条件分岐命令によって置き換えられる。パッチン
グの行われる命令のロケーションを「パッチング・サイ
ト」２０と呼ぶ。したがって、ロード・オブジェクト内
のあるロケーションにロード命令がある場合、そのロケ
ーションは「パッチング・サイト」２０と呼ばれること
となる。エラー・チェックが行われるメモリ・ロケーシ
ョンは「パッチング領域」５０と呼ばれる。各パッチン
グ領域５０に対して、パッチング領域６０の１つまたは
複数のセクションがあり、各セクションは一意のパッチ
ング・サイトに対応している。したがって、１０００の
パッチング・サイトがある場合、パッチング領域のセク
ションは１０００あることになる。
【００３４】ロード・オブジェクト内で置き換えられる
各命令に対して、パッチング領域６０の対応するセクシ
ョンへ分岐する命令がある。それ故、各パッチング・サ
イト２０に対する全ロード・オブジェクトに割り当てら
れている所与のパッチング領域５０にはパッチング領域
のカスタム・セクション６０があり、各パッチング領域
２０はパッチング領域６０内のそれ自体のカスタム・セ
クションへの分岐と置き換えられる。パッチング領域６
０のこれらのセクションは、メモリ内の個別の領域で何
らかの実際のチェック・コード７０を呼び出すように設
定された数個の命令からなっている。好ましい実施形態
において、この実チェック・コード７０はライブラリ・
ルーチン「librtc.so」で示されている。それ故、「lib
rtc.so」はチェックを行うパッチング領域５０によって
呼び出される。報告する何らかのエラーがある場合、
「librtc.so 」はそのエラーをエラー・バッファに記録
し、このエラー・バッファからデバッガ・プログラムが
これらのエラーを報告する。それ以外の場合、プロセス
はパッチング領域６０に戻り、次いで、プロセスはユー
ザ・プログラムで実行される次の命令へ戻る。パッチン
グの行われる命令のタイプに応じて、さまざまなタイプ
のパッチング領域のセクションがある。また、個別に取
り扱わなければならない分岐命令の遅延により、数種類
の場合がある。したがって、パッチング領域６０のセク
ションは同一のものではなく、「librtc.so 」ルーチン
はパッチング領域６０のセクションの計装化命令がこの
ルーチンを呼び出すさまざまな態様に応じて、さまざま
な種類のテストを行う。要約すると、パッチング領域の
セクションは本来、ある特定のパッチングに対するもの
である。図３はパッチング・サイトがパッチング領域６
０のセクションへの分岐、ならびにチェック・コード７
０への他の分岐によって置き換えられ、ユーザ・プログ
ラムで実行される次の命令に戻るプロセスを示してい
る。図３を変更することになる他の場合がある。たとえ
ば、パッチングが行われる命令が分岐の遅延スロット、
すなわち遅延分岐命令内にある場合、パッチング領域お
よびチェック・コードに分岐した後、プロセスはシーケ
ンス内の次の命令に戻る分岐をするのではなく、エラー
チェック前にプロセスが分岐すると考えられるアドレス
・ロケーションへ分岐しなければならない。マルチスレ
ッド（ＭＴ）に合わせて作成されたターゲット・アプリ
ケーション・プロセスを取り扱うために、これらのパッ
チング領域とエラー・チェック・ルーチンのうちいくつ
かを、以下で詳述するように変更しなければならない。
これらの変更を理解させるため、典型的なマルチプロセ
ッシング環境を説明することがまず必要となる。
各命令に対して、パッチング領域６０の対応するセクシ
ョンへ分岐する命令がある。それ故、各パッチング・サ
イト２０に対する全ロード・オブジェクトに割り当てら
れている所与のパッチング領域５０にはパッチング領域
のカスタム・セクション６０があり、各パッチング領域
２０はパッチング領域６０内のそれ自体のカスタム・セ
クションへの分岐と置き換えられる。パッチング領域６
０のこれらのセクションは、メモリ内の個別の領域で何
らかの実際のチェック・コード７０を呼び出すように設
定された数個の命令からなっている。好ましい実施形態
において、この実チェック・コード７０はライブラリ・
ルーチン「librtc.so」で示されている。それ故、「lib
rtc.so」はチェックを行うパッチング領域５０によって
呼び出される。報告する何らかのエラーがある場合、
「librtc.so 」はそのエラーをエラー・バッファに記録
し、このエラー・バッファからデバッガ・プログラムが
これらのエラーを報告する。それ以外の場合、プロセス
はパッチング領域６０に戻り、次いで、プロセスはユー
ザ・プログラムで実行される次の命令へ戻る。パッチン
グの行われる命令のタイプに応じて、さまざまなタイプ
のパッチング領域のセクションがある。また、個別に取
り扱わなければならない分岐命令の遅延により、数種類
の場合がある。したがって、パッチング領域６０のセク
ションは同一のものではなく、「librtc.so 」ルーチン
はパッチング領域６０のセクションの計装化命令がこの
ルーチンを呼び出すさまざまな態様に応じて、さまざま
な種類のテストを行う。要約すると、パッチング領域の
セクションは本来、ある特定のパッチングに対するもの
である。図３はパッチング・サイトがパッチング領域６
０のセクションへの分岐、ならびにチェック・コード７
０への他の分岐によって置き換えられ、ユーザ・プログ
ラムで実行される次の命令に戻るプロセスを示してい
る。図３を変更することになる他の場合がある。たとえ
ば、パッチングが行われる命令が分岐の遅延スロット、
すなわち遅延分岐命令内にある場合、パッチング領域お
よびチェック・コードに分岐した後、プロセスはシーケ
ンス内の次の命令に戻る分岐をするのではなく、エラー
チェック前にプロセスが分岐すると考えられるアドレス
・ロケーションへ分岐しなければならない。マルチスレ
ッド（ＭＴ）に合わせて作成されたターゲット・アプリ
ケーション・プロセスを取り扱うために、これらのパッ
チング領域とエラー・チェック・ルーチンのうちいくつ
かを、以下で詳述するように変更しなければならない。
これらの変更を理解させるため、典型的なマルチプロセ
ッシング環境を説明することがまず必要となる。
【００３５】マルチプロセッシング環境 図４はマルチスレッド・ターゲット・プログラムで使用
するのに典型的なものである代表的なマルチプロセッサ
機械構成を示す。しかしながら、マルチスレッド・プロ
グラムはマルチプロセッサ・システムだけではなく、シ
ングルプロセッサ・システムでも作動できるが、シング
ルプロセッサ・システムでは効率よく作動できないだけ
であることに留意すべきである。本発明、すなわちＲＴ
Ｃ／ＭＴはいずれのタイプのシステムでも作動できる。
好ましい実施形態においては、ＳｕｎＯＳ ５．０が使
用されるオペレーティング・システムであり、これはＳ
ｕｎ Ｓｏｌａｒｉｓ作動環境の一部である。ＳｕｎＯ
Ｓ ５．０は１つまたは複数のプロセッサを備えた密結
合共用メモリ・マルチプロセッサ・システムで作動する
ことを目的としたものである。個々で、図４を参照する
と、典型的なマルチプロセッサ・コンピュータ・システ
ムはメモリ４２０およびクロック４１８を共用する１つ
または複数の中央演算処理装置（ＣＰＵ）４１０、４１
２、４１４を有するものと考えられる。オペレーティン
グ・システム・カーネル４１６はすべてのプロセッサが
同等なものであるとみなす。プロセッサ４１０、４１
２、４１４は作動可能カーネル・スレッド４２６の待ち
行列から選択したカーネル・スレッドを実行する。特定
のマルチプロセッサ実施形態が非対称のロード（たとえ
ば、割込み）をプロセッサにおいた場合、カーネル４１
６はそれにかかわりなく、プロセッサ４１０、４１２、
４１４に、これらが同等のものであるかのようにして、
スレッドをスケジュールする。一般に、すべてのプロセ
ッサ４１０、４１２、４１４はメモリ４２０内の同じデ
ータを見る。このモデルはプロセッサ４１０、４１２、
４１４が発行したメモリ操作が、他のプロセッサから見
たときに遅延または並べ変えられるという点で、若干緩
和されている。この環境においては、メモリに対する共
用アクセスが同期化オブジェクト４２４によって保護さ
れることが好ましい。場合によっては、データ・ロッキ
ング機構は同期化変数あるいは同期化プリミティブとも
呼ばれる。例外は単一のプリミティブ・データ項目が原
子的に読み取られるか、更新される（たとえば、ワード
内のすべてのバイトが同時に変化する）ことである。
「ワード」は４バイトのデータである。共用メモリ４２
０は対称的であると想定する。それ故、カーネル４１６
はここでは、特定のプロセッサ４１０（たとえば）にス
ケジュールされたプロセスが、そのプロセッサ４１０か
らより迅速にアクセスされるメモリ４２０の特定の部分
におかれることを保証しない。カーネル４１６がマルチ
プロセッサで「対称的」に作動するが、４１０、４１
２、４１４のうち２つ以上のプロセッサがカーネル・コ
ード４１６を実行することを認めないようにすることが
できる。これがプロセッサの数が増えることにあった方
式でないことは明らかであり、本発明の好ましい実施形
態においては、システム内のすべてのプロセッサ４１
０、４１２、４１４は共用カーネル・コード４１６を同
時に実行し、共用メモリ４２０内のデータ構造を使用し
て、必要に応じ、プロセッサ４１０、４１２、４１４の
間の通信を行うことができる。したがって、同一のメモ
リ・ロケーションを並行にアクセスしている複数のスレ
ッドを有するプロセスをデバッグする場合、メモリ・ロ
ケーションがこれにアクセスしているスレッド以外のス
レッドに割り当てられるかどうかを、デバッガが知らせ
ることができるのが必須である。すなわち、スレッド１
がアクセスしているメモリ・ロケーションはスレッド２
のスタックにある可能性があり、そうであれば、有効な
メモリ・ロケーションにある。従来技術のデバッガはこ
の後者の場合を、まちがって、メモリ・アクセス・エラ
ーと報告する。
するのに典型的なものである代表的なマルチプロセッサ
機械構成を示す。しかしながら、マルチスレッド・プロ
グラムはマルチプロセッサ・システムだけではなく、シ
ングルプロセッサ・システムでも作動できるが、シング
ルプロセッサ・システムでは効率よく作動できないだけ
であることに留意すべきである。本発明、すなわちＲＴ
Ｃ／ＭＴはいずれのタイプのシステムでも作動できる。
好ましい実施形態においては、ＳｕｎＯＳ ５．０が使
用されるオペレーティング・システムであり、これはＳ
ｕｎ Ｓｏｌａｒｉｓ作動環境の一部である。ＳｕｎＯ
Ｓ ５．０は１つまたは複数のプロセッサを備えた密結
合共用メモリ・マルチプロセッサ・システムで作動する
ことを目的としたものである。個々で、図４を参照する
と、典型的なマルチプロセッサ・コンピュータ・システ
ムはメモリ４２０およびクロック４１８を共用する１つ
または複数の中央演算処理装置（ＣＰＵ）４１０、４１
２、４１４を有するものと考えられる。オペレーティン
グ・システム・カーネル４１６はすべてのプロセッサが
同等なものであるとみなす。プロセッサ４１０、４１
２、４１４は作動可能カーネル・スレッド４２６の待ち
行列から選択したカーネル・スレッドを実行する。特定
のマルチプロセッサ実施形態が非対称のロード（たとえ
ば、割込み）をプロセッサにおいた場合、カーネル４１
６はそれにかかわりなく、プロセッサ４１０、４１２、
４１４に、これらが同等のものであるかのようにして、
スレッドをスケジュールする。一般に、すべてのプロセ
ッサ４１０、４１２、４１４はメモリ４２０内の同じデ
ータを見る。このモデルはプロセッサ４１０、４１２、
４１４が発行したメモリ操作が、他のプロセッサから見
たときに遅延または並べ変えられるという点で、若干緩
和されている。この環境においては、メモリに対する共
用アクセスが同期化オブジェクト４２４によって保護さ
れることが好ましい。場合によっては、データ・ロッキ
ング機構は同期化変数あるいは同期化プリミティブとも
呼ばれる。例外は単一のプリミティブ・データ項目が原
子的に読み取られるか、更新される（たとえば、ワード
内のすべてのバイトが同時に変化する）ことである。
「ワード」は４バイトのデータである。共用メモリ４２
０は対称的であると想定する。それ故、カーネル４１６
はここでは、特定のプロセッサ４１０（たとえば）にス
ケジュールされたプロセスが、そのプロセッサ４１０か
らより迅速にアクセスされるメモリ４２０の特定の部分
におかれることを保証しない。カーネル４１６がマルチ
プロセッサで「対称的」に作動するが、４１０、４１
２、４１４のうち２つ以上のプロセッサがカーネル・コ
ード４１６を実行することを認めないようにすることが
できる。これがプロセッサの数が増えることにあった方
式でないことは明らかであり、本発明の好ましい実施形
態においては、システム内のすべてのプロセッサ４１
０、４１２、４１４は共用カーネル・コード４１６を同
時に実行し、共用メモリ４２０内のデータ構造を使用し
て、必要に応じ、プロセッサ４１０、４１２、４１４の
間の通信を行うことができる。したがって、同一のメモ
リ・ロケーションを並行にアクセスしている複数のスレ
ッドを有するプロセスをデバッグする場合、メモリ・ロ
ケーションがこれにアクセスしているスレッド以外のス
レッドに割り当てられるかどうかを、デバッガが知らせ
ることができるのが必須である。すなわち、スレッド１
がアクセスしているメモリ・ロケーションはスレッド２
のスタックにある可能性があり、そうであれば、有効な
メモリ・ロケーションにある。従来技術のデバッガはこ
の後者の場合を、まちがって、メモリ・アクセス・エラ
ーと報告する。
【００３６】図４の説明を継続すると、「ｃｐｕ構造領
域」４１５は各プロセッサ４１０、４１２、４１４に対
するデータ構造を含んでいる。これらのプロセッサごと
の構造は、現在実行中のスレッド、遊休スレッド、現行
のディスパッチング優先順位、および割込み処理情報な
どのプロセッサごとのデータを含んでいる。
域」４１５は各プロセッサ４１０、４１２、４１４に対
するデータ構造を含んでいる。これらのプロセッサごと
の構造は、現在実行中のスレッド、遊休スレッド、現行
のディスパッチング優先順位、および割込み処理情報な
どのプロセッサごとのデータを含んでいる。
【００３７】ＳｕｎＯＳ ５．０はできるだけ多くのプ
ロセッサ４１０、４１２、４１４を利用する相対的に
「細かい」ロッキング方式で設計されている。各カーネ
ル・サブシステムは頻繁な操作に対して高度な並行度を
可能とするロッキング方式を有している。一般に、デー
タ項目４２２に対するアクセスはロックによって保護さ
れており、ルーチン全体に対するアクセスのロックでは
ない。まれな操作には通常、単純な相互排除による粗い
ロックがかけられる。全体として、ＳｕｎＯＳ５．０は
静的には数百の別個の同期化オブジェクト４２４を有し
ており、動的には数千の同期化オブジェクト４２４を有
している。カーネル・スレッドは次のような各種の同期
化オブジェクトないしプリミティブによって同期化を行
う。
ロセッサ４１０、４１２、４１４を利用する相対的に
「細かい」ロッキング方式で設計されている。各カーネ
ル・サブシステムは頻繁な操作に対して高度な並行度を
可能とするロッキング方式を有している。一般に、デー
タ項目４２２に対するアクセスはロックによって保護さ
れており、ルーチン全体に対するアクセスのロックでは
ない。まれな操作には通常、単純な相互排除による粗い
ロックがかけられる。全体として、ＳｕｎＯＳ５．０は
静的には数百の別個の同期化オブジェクト４２４を有し
ており、動的には数千の同期化オブジェクト４２４を有
している。カーネル・スレッドは次のような各種の同期
化オブジェクトないしプリミティブによって同期化を行
う。
【００３８】相互排除（ｍｕｔｅｘ）ロック 条件変数 計数セマフォ 複数リーダー、単一ライター（リーダーズ／ライター）
ロック
ロック
【００３９】ｍｕｔｅｘおよびライター・ロックは優先
順位の低いスレッドが優先順位の高いスレッドをブロッ
クする（優先順位の反転）のを防止するディスパッチン
グ優先順位継承プロトコルをサポートしている。
順位の低いスレッドが優先順位の高いスレッドをブロッ
クする（優先順位の反転）のを防止するディスパッチン
グ優先順位継承プロトコルをサポートしている。
【００４０】スレッドについての付加的な情報により、
ＵＮＩＸオペレーティング・システム環境における「プ
ロセス」を定義する必要がある。
ＵＮＩＸオペレーティング・システム環境における「プ
ロセス」を定義する必要がある。
【００４１】ＵＮＩＸ（登録商標）オペレーティング・
システムはＳｕｎＯＳ ５．０（Ｓｏｌａｒｉｓ）オペ
レーティング・システムの基礎であり、世界中で数千台
のコンピュータ・システムで現在使用されている。ＵＮ
ＩＸはアメリカ合衆国およびその他の国々における登録
商標であり、Ｘ／ＯＰＥＮ Ｌｔｄ．によって独占実施
権が与えられているものである。ＵＮＩＸは階層ファイ
ル・システムを備えた単純なタイムシェアリング・シス
テムとして設計されており、複数の「プロセス」をサポ
ートしている。「プロセス」はプログラムの実行であ
り、ＣＰＵが機械命令（テキスト）、データおよびスタ
ックとして解釈するバイトのパターンからなっている。
「スタック」は一連のハードウェア・レジスタまたはメ
イン・メモリの予約された量であり、演算に使用された
り、内部操作の追跡に使用されるものである。スタック
は通常、後入れ先出しベースで動作する。すなわち、ス
タックにおかれる（プッシュされる）最後の項目または
アドレスが、スタックから除去される（ポップされる）
最初の項目となる。数個のプロセスが単一のプログラム
のインスタンスとなることができる。プロセスは「シス
テム・コール」により他のプロセスおよびカーネルと通
信を行う。プロセスは「ユーザ」モードおよび「カーネ
ル」モードの両方で実行でき、したがって、各モードに
対して独立したスタックを有している。プロセスの「コ
ンテキスト」またはその「状態」は次のように定義され
る。
システムはＳｕｎＯＳ ５．０（Ｓｏｌａｒｉｓ）オペ
レーティング・システムの基礎であり、世界中で数千台
のコンピュータ・システムで現在使用されている。ＵＮ
ＩＸはアメリカ合衆国およびその他の国々における登録
商標であり、Ｘ／ＯＰＥＮ Ｌｔｄ．によって独占実施
権が与えられているものである。ＵＮＩＸは階層ファイ
ル・システムを備えた単純なタイムシェアリング・シス
テムとして設計されており、複数の「プロセス」をサポ
ートしている。「プロセス」はプログラムの実行であ
り、ＣＰＵが機械命令（テキスト）、データおよびスタ
ックとして解釈するバイトのパターンからなっている。
「スタック」は一連のハードウェア・レジスタまたはメ
イン・メモリの予約された量であり、演算に使用された
り、内部操作の追跡に使用されるものである。スタック
は通常、後入れ先出しベースで動作する。すなわち、ス
タックにおかれる（プッシュされる）最後の項目または
アドレスが、スタックから除去される（ポップされる）
最初の項目となる。数個のプロセスが単一のプログラム
のインスタンスとなることができる。プロセスは「シス
テム・コール」により他のプロセスおよびカーネルと通
信を行う。プロセスは「ユーザ」モードおよび「カーネ
ル」モードの両方で実行でき、したがって、各モードに
対して独立したスタックを有している。プロセスの「コ
ンテキスト」またはその「状態」は次のように定義され
る。
【００４２】プロセスのテキスト 大域ユーザ変数およびデータ構造の値 レジスタの値 プロセスのプロセス・テーブル・スロットおよび「ｕ領
域」に格納された値 プロセスのユーザおよびカーネル・スタックの内容
域」に格納された値 プロセスのユーザおよびカーネル・スタックの内容
【００４３】「プロセス・テーブル」および「ｕ領域」
は両方ともプロセスの状態を記述したデータ構造であ
る。同一プロセスでのユーザ・モードからカーネル・モ
ードへの切り換えは「コンテキスト切り換え」を必要と
しないが、プロセス「Ａ」からプロセス「Ｂ」に切り換
えるときには、コンテキスト切り換えを行わなければな
らない。「コンテキスト切り換え」では、カーネルがす
べてのレジスタと値をセーブして、プロセスを再開始し
たときに、以前のコンテキスト切り換えが行われたとき
実行されていたところから再開されるようにする必要が
ある。
は両方ともプロセスの状態を記述したデータ構造であ
る。同一プロセスでのユーザ・モードからカーネル・モ
ードへの切り換えは「コンテキスト切り換え」を必要と
しないが、プロセス「Ａ」からプロセス「Ｂ」に切り換
えるときには、コンテキスト切り換えを行わなければな
らない。「コンテキスト切り換え」では、カーネルがす
べてのレジスタと値をセーブして、プロセスを再開始し
たときに、以前のコンテキスト切り換えが行われたとき
実行されていたところから再開されるようにする必要が
ある。
【００４４】「プロセス」の概念は「スレッド」および
「マルチスレッド」システムに拡張される。「制御のス
レッド」ないし簡単には「スレッド」とはプログラムで
実行されている命令のシーケンスである。スレッドは、
ローカル変数および復帰アドレスを追跡するためのプロ
グラム・カウンタ（ＰＣ）およびスタックを有してい
る。各スレッドは独立して実行される。スレッドはプロ
セス命令とそのデータのほとんどを共用し、またプロセ
スのオペレーティング・システム状態のほとんどを共用
している。各スレッドは任意のシステム・コールを行う
ことができる。オペレーティング・システムはスレッド
をいずれかの利用可能なプロセッサ（ＣＰＵ）にディス
パッチし、スケジュールすることによって、スレッドの
実行を管理する。スレッドおよび関連する制御、ならび
にマルチスレッド・システムのサービス（同期化サービ
スを含む）をオブジェクトとして実施することもでき
る。オブジェクトとして実施される同期化技法として
は、相互排除（ｍｕｔｅｘ）ロック、セマフォ、条件変
数、およびリーダーズ／ライター・ロックなどがある。
ユニプロセッサ構成のシステムの以前のＲＴＣテスト機
能は複数のスレッドを扱うように設計されていなかった
ため、ある種のメモリ・ロケーションを無効なものであ
るとまちがって通知することがあるが、これは他のスレ
ッドが他のプロセッサで作動しており、指定されたメモ
リ・ロケーションの状況に影響を及ぼすことがあること
をＲＴＣシステムが認識していないからである。
「マルチスレッド」システムに拡張される。「制御のス
レッド」ないし簡単には「スレッド」とはプログラムで
実行されている命令のシーケンスである。スレッドは、
ローカル変数および復帰アドレスを追跡するためのプロ
グラム・カウンタ（ＰＣ）およびスタックを有してい
る。各スレッドは独立して実行される。スレッドはプロ
セス命令とそのデータのほとんどを共用し、またプロセ
スのオペレーティング・システム状態のほとんどを共用
している。各スレッドは任意のシステム・コールを行う
ことができる。オペレーティング・システムはスレッド
をいずれかの利用可能なプロセッサ（ＣＰＵ）にディス
パッチし、スケジュールすることによって、スレッドの
実行を管理する。スレッドおよび関連する制御、ならび
にマルチスレッド・システムのサービス（同期化サービ
スを含む）をオブジェクトとして実施することもでき
る。オブジェクトとして実施される同期化技法として
は、相互排除（ｍｕｔｅｘ）ロック、セマフォ、条件変
数、およびリーダーズ／ライター・ロックなどがある。
ユニプロセッサ構成のシステムの以前のＲＴＣテスト機
能は複数のスレッドを扱うように設計されていなかった
ため、ある種のメモリ・ロケーションを無効なものであ
るとまちがって通知することがあるが、これは他のスレ
ッドが他のプロセッサで作動しており、指定されたメモ
リ・ロケーションの状況に影響を及ぼすことがあること
をＲＴＣシステムが認識していないからである。
【００４５】複数のスレッドを取り扱うためのＲＴＣの
変更 上述したように、本発明の好ましい実施形態はＳｕｎ
Ｓｏｌａｒｉｓオペレーティング・システム、Ｓｕｎ
ＳＰＡＲＣＷｏｒｋｓデバッガ（「ｄｂｘ」デバッガ）
を利用しており、このデバッガは実行時チェック（ＲＴ
Ｃ）ルーチンを含んでおり、このルーチン自体はライブ
ラリ・ルーチン「librtc.so 」の一般メモリ状況保守お
よびメモリ状況チェッカ機能を利用している。ターゲッ
ト・アプリケーション・プログラムがデバッガの制御の
下でのテストのために機械にロードされ、実行時チェッ
クをユーザが指定したとき、デバッガのＲＴＣ部分がタ
ーゲット・アプリケーション・プログラムのプロセスに
パッチングを行い、「librtc.so 」ライブラリ・ルーチ
ンがメモリ状況を保守し、メモリ・アクセスをチェック
するために、メモリ・アクセス・パッチング・コードの
各タイプごとに各種の態様およびモードで使用される。
このシステムをマルチスレッドのターゲット・アプリケ
ーション・プログラムを取り扱うように変更するには、
ユニプロセッサ・デバッガ／ＲＴＣシステムに以下の一
般的な変更を行う必要がある。
変更 上述したように、本発明の好ましい実施形態はＳｕｎ
Ｓｏｌａｒｉｓオペレーティング・システム、Ｓｕｎ
ＳＰＡＲＣＷｏｒｋｓデバッガ（「ｄｂｘ」デバッガ）
を利用しており、このデバッガは実行時チェック（ＲＴ
Ｃ）ルーチンを含んでおり、このルーチン自体はライブ
ラリ・ルーチン「librtc.so 」の一般メモリ状況保守お
よびメモリ状況チェッカ機能を利用している。ターゲッ
ト・アプリケーション・プログラムがデバッガの制御の
下でのテストのために機械にロードされ、実行時チェッ
クをユーザが指定したとき、デバッガのＲＴＣ部分がタ
ーゲット・アプリケーション・プログラムのプロセスに
パッチングを行い、「librtc.so 」ライブラリ・ルーチ
ンがメモリ状況を保守し、メモリ・アクセスをチェック
するために、メモリ・アクセス・パッチング・コードの
各タイプごとに各種の態様およびモードで使用される。
このシステムをマルチスレッドのターゲット・アプリケ
ーション・プログラムを取り扱うように変更するには、
ユニプロセッサ・デバッガ／ＲＴＣシステムに以下の一
般的な変更を行う必要がある。
【００４６】Ｓｏｌａｒｉｓオペレーティング・システ
ム オペレーティング・システムの現行バージョンがマルチ
スレッド・システムおよびマルチプロセッサ・ハードウ
ェア・システムを扱うように設計されているので、変更
は何も必要ない。
ム オペレーティング・システムの現行バージョンがマルチ
スレッド・システムおよびマルチプロセッサ・ハードウ
ェア・システムを扱うように設計されているので、変更
は何も必要ない。
【００４７】ＳＰＡＲＣＷｏｒｋｓデバッガ（「ｄｂ
ｘ」） このルーチンはターゲット・アプリケーション・プログ
ラムのプロセスがマルチスレッド・タイプであることを
認識し、ライブラリ・ルーチン「libthread_db」にリン
クし、これを動的にロードするように変更された。ライ
ブラリ・ルーチン「libthread 」がユーザのターゲット
・アプリケーション・プログラムとリンクされることに
留意すべきである。ルーチン「libthread_db」は次のよ
うな作動しているスレッドに関する情報を含んでいる。
ｘ」） このルーチンはターゲット・アプリケーション・プログ
ラムのプロセスがマルチスレッド・タイプであることを
認識し、ライブラリ・ルーチン「libthread_db」にリン
クし、これを動的にロードするように変更された。ライ
ブラリ・ルーチン「libthread 」がユーザのターゲット
・アプリケーション・プログラムとリンクされることに
留意すべきである。ルーチン「libthread_db」は次のよ
うな作動しているスレッドに関する情報を含んでいる。
【００４８】スレッドＩＤ このスレッドに対するレジスタ・セット このスレッドに対するスタック プログラム・カウンタ スレッド固有のデータ・キー 信号マスク 保留信号
【００４９】このルーチンのエラー報告セクションはス
レッドＩＤによってエラーを報告し、スレッド固有のエ
ラー・バッファからそのスレッドのエラーを取得するよ
う変更された。
レッドＩＤによってエラーを報告し、スレッド固有のエ
ラー・バッファからそのスレッドのエラーを取得するよ
う変更された。
【００５０】ｄｂｘの実行時チェック（「ＲＴＣ」）セ
クション ＲＴＣセクションはユーザ・ターゲット・アプリケーシ
ョン・プログラム（「ターゲット・プログラム」）がマ
ルチスレッドであるかどうかをまず特定するように変更
された。これはターゲット・プログラムが「libthread
」ライブラリにリンクされているかどうかをチェック
することによって行われる。リンクされている場合、Ｒ
ＴＣは（１）ｄｂｘが「libthread_db」の適切な修正バ
ージョン（下記参照）を見つけだし、ロードできるかど
うか、および（２）ターゲット・プログラムが「libthr
ead 」の適切な修正バージョンとリンクされているかど
うかをチェックする。上述のように、「libthread 」お
よび「libthread_db」は両方とも変更され、本発明のＲ
ＴＣ／ＭＴとともに作動するように特に拡張された。こ
れらのサポートしているライブラリが見つかると、ＲＴ
Ｃもライブラリ・ルーチン「librtc.so 」を初期化し、
これにターゲット・プログラムがマルチスレッドである
と通知するように変更される。
クション ＲＴＣセクションはユーザ・ターゲット・アプリケーシ
ョン・プログラム（「ターゲット・プログラム」）がマ
ルチスレッドであるかどうかをまず特定するように変更
された。これはターゲット・プログラムが「libthread
」ライブラリにリンクされているかどうかをチェック
することによって行われる。リンクされている場合、Ｒ
ＴＣは（１）ｄｂｘが「libthread_db」の適切な修正バ
ージョン（下記参照）を見つけだし、ロードできるかど
うか、および（２）ターゲット・プログラムが「libthr
ead 」の適切な修正バージョンとリンクされているかど
うかをチェックする。上述のように、「libthread 」お
よび「libthread_db」は両方とも変更され、本発明のＲ
ＴＣ／ＭＴとともに作動するように特に拡張された。こ
れらのサポートしているライブラリが見つかると、ＲＴ
Ｃもライブラリ・ルーチン「librtc.so 」を初期化し、
これにターゲット・プログラムがマルチスレッドである
と通知するように変更される。
【００５１】ＲＴＣは「メモリ漏れチェック」モードに
なっているときに、各スレッドに対するスタックとレジ
スタ・セットを対話式にチェックして、漏れ状況データ
を更新するために以前に割り当てられたメモリに対する
ポインタを探すようにも変更された。
なっているときに、各スレッドに対するスタックとレジ
スタ・セットを対話式にチェックして、漏れ状況データ
を更新するために以前に割り当てられたメモリに対する
ポインタを探すようにも変更された。
【００５２】ライブラリ・ルーチン「librtc.so 」 すべてのスレッドが同一の「ヒープ」領域からのスペー
スを割り当てるので、librtc.soはスレッドによる「mal
loc」、「realloc」および「free」コマンドの実行を監
視することによって、メモリ・スペースの並行割当てお
よび解放を管理するように変更された。これらのヒープ
・メモリ割当ておよび割当て解除関数は同期化プリミテ
ィブを使用して、一時に１つのスレッドだけがヒープ・
メモリの配置を追跡するヒープ・データ構造を処理でき
るようにする。
スを割り当てるので、librtc.soはスレッドによる「mal
loc」、「realloc」および「free」コマンドの実行を監
視することによって、メモリ・スペースの並行割当てお
よび解放を管理するように変更された。これらのヒープ
・メモリ割当ておよび割当て解除関数は同期化プリミテ
ィブを使用して、一時に１つのスレッドだけがヒープ・
メモリの配置を追跡するヒープ・データ構造を処理でき
るようにする。
【００５３】スレッドのスタックのスペースは適正にア
クセスできるメモリである。librtc.so のコードはすべ
てのスレッドのスタックを認識するよう変更されたの
で、これらのスタック上およびスタック外のスペースに
対するメモリ・アクセスを正しくチェックできる。スレ
ッドのさまざまな関数が呼び出され、戻されるたびに、
スタックは伸縮する。librtc.so のコードは最後に知っ
た値を現在の値と比較することによってスタックの伸縮
を検出する。スタックが伸びた場合、librtc.soはその
内部データ構造を調節して、追加のメモリが適正に割り
当てられたことを反映する。スタックが縮んだ場合に
は、librtc.so は少ないメモリが適切に割り当てられる
ことを認識する。
クセスできるメモリである。librtc.so のコードはすべ
てのスレッドのスタックを認識するよう変更されたの
で、これらのスタック上およびスタック外のスペースに
対するメモリ・アクセスを正しくチェックできる。スレ
ッドのさまざまな関数が呼び出され、戻されるたびに、
スタックは伸縮する。librtc.so のコードは最後に知っ
た値を現在の値と比較することによってスタックの伸縮
を検出する。スタックが伸びた場合、librtc.soはその
内部データ構造を調節して、追加のメモリが適正に割り
当てられたことを反映する。スタックが縮んだ場合に
は、librtc.so は少ないメモリが適切に割り当てられる
ことを認識する。
【００５４】librtc.so はＭＴ安全となるようにも変更
された。すなわち、同期化ロックがクリティカル・コー
ド領域に挿入され、異なるスレッド・ロケーション・テ
ストによるlibrtc.soへの並行アクセスを一貫して処理
できるようになった。librtc.soはアクセス権（読取り
専用、書込み専用、読み書き、アクセスなし）を追跡す
るメモリ状況のデータ構造を維持する。このデータ構造
を一時に２つ以上のスレッドによって安全に変更するこ
とはできず、したがって、これらのデータ構造をスレッ
ドによる並行アクセスから保護する必要がある。同期化
プリミティブ（ロック）がデータの一貫性を維持するた
めこれらのデータ構造にアクセスするコードのまわりに
おかれる。
された。すなわち、同期化ロックがクリティカル・コー
ド領域に挿入され、異なるスレッド・ロケーション・テ
ストによるlibrtc.soへの並行アクセスを一貫して処理
できるようになった。librtc.soはアクセス権（読取り
専用、書込み専用、読み書き、アクセスなし）を追跡す
るメモリ状況のデータ構造を維持する。このデータ構造
を一時に２つ以上のスレッドによって安全に変更するこ
とはできず、したがって、これらのデータ構造をスレッ
ドによる並行アクセスから保護する必要がある。同期化
プリミティブ（ロック）がデータの一貫性を維持するた
めこれらのデータ構造にアクセスするコードのまわりに
おかれる。
【００５５】librtc.soはキーlibthread関数に対するラ
ッパを追加するように変更されたので、librtc.soをこ
れらの関数に対する呼出しに挿入することができる。li
bthread関数に対するこのような呼出しがインターセプ
トされると、librtc.soは渡されるパラメータ（すなわ
ち、ファンクション・コールに対する引数）を適正にタ
ーゲット・メモリから書き出し／読み込みできるかどう
かをチェックする。
ッパを追加するように変更されたので、librtc.soをこ
れらの関数に対する呼出しに挿入することができる。li
bthread関数に対するこのような呼出しがインターセプ
トされると、librtc.soは渡されるパラメータ（すなわ
ち、ファンクション・コールに対する引数）を適正にタ
ーゲット・メモリから書き出し／読み込みできるかどう
かをチェックする。
【００５６】librtc.soコードはＲＴＣに対して計装さ
れている関数を呼び出す。librtc.soが計装されている
関数を呼び出すと、librtc.so に追加された同期化プリ
ミティブのため、デッドロックが生じる可能性がある。
たとえば、librtc.so がロックを取得し、関数を呼び出
した結果として、librtc.so コードに再度入り、同じ同
期化プリミティブを再度取得しようとした場合、デッド
ロックが生じる。このデッドロックを回避するために、
librtc.so は他のライブラリでコードを実行していると
き、それ自体を使用禁止とする（すなわち、エラー・チ
ェック関数を実行しない）ように変更された。各スレッ
ドはエラー・チェックが行われるのか、使用禁止とされ
ているのかを示すフラグを維持する。
れている関数を呼び出す。librtc.soが計装されている
関数を呼び出すと、librtc.so に追加された同期化プリ
ミティブのため、デッドロックが生じる可能性がある。
たとえば、librtc.so がロックを取得し、関数を呼び出
した結果として、librtc.so コードに再度入り、同じ同
期化プリミティブを再度取得しようとした場合、デッド
ロックが生じる。このデッドロックを回避するために、
librtc.so は他のライブラリでコードを実行していると
き、それ自体を使用禁止とする（すなわち、エラー・チ
ェック関数を実行しない）ように変更された。各スレッ
ドはエラー・チェックが行われるのか、使用禁止とされ
ているのかを示すフラグを維持する。
【００５７】変更されたその他のルーチン 上述したようなライブラリ・ルーチン「libthread_db」
および「libthread」自体が変更された。プロセスがス
レッドを作成し、スレッドを維持する後者の「libthrea
d 」は変更され、スレッドのスタックのロケーションと
サイズに関する情報を返す関数を提供するようになっ
た。このlibthreadの関数は、librtc.soのコードによっ
て使用される。スレッドＩＤおよびレジスタ・セットな
どの上述のように作動しているスレッド、およびスタッ
クに関する情報をもたらすルーチン「libthread_db」は
変更され、スタック・サイズおよびスレッドのロケーシ
ョンについての情報を有するｄｂｘをもたらすようにな
った。
および「libthread」自体が変更された。プロセスがス
レッドを作成し、スレッドを維持する後者の「libthrea
d 」は変更され、スレッドのスタックのロケーションと
サイズに関する情報を返す関数を提供するようになっ
た。このlibthreadの関数は、librtc.soのコードによっ
て使用される。スレッドＩＤおよびレジスタ・セットな
どの上述のように作動しているスレッド、およびスタッ
クに関する情報をもたらすルーチン「libthread_db」は
変更され、スタック・サイズおよびスレッドのロケーシ
ョンについての情報を有するｄｂｘをもたらすようにな
った。
【００５８】ここで図５を参照すると、既存のＲＴＣシ
ステムに対して行われた修正を示す図が示されている。
ルーチン「librtc.so 」７０は呼び出されたとき、ユニ
プロセッサ・モードなのか、マルチスレッド・モードな
のかについて決定しなければならない。ユニプロセッサ
・モードである場合、処理は図３に関して上述したよう
にして継続する。マルチスレッド・モードである場合、
「librtc.so 」はそのメモリ状況保守８０およびチェッ
ク８６を「スレッドごと」に行い、スレッドＩＤ、スレ
ッドのスタック・サイズ、スタック・ベース・アドレ
ス、変更された「libthread 」ルーチン８４から得られ
るスタック限度などの各スレッドに関する情報を維持す
る。ｄｂｘ ＲＴｃルーチンも漏れのチェック時に、変
更された「libthread_db」ルーチン８２から取得される
このようなスレッドごとの情報を必要とすることに留意
されたい。
ステムに対して行われた修正を示す図が示されている。
ルーチン「librtc.so 」７０は呼び出されたとき、ユニ
プロセッサ・モードなのか、マルチスレッド・モードな
のかについて決定しなければならない。ユニプロセッサ
・モードである場合、処理は図３に関して上述したよう
にして継続する。マルチスレッド・モードである場合、
「librtc.so 」はそのメモリ状況保守８０およびチェッ
ク８６を「スレッドごと」に行い、スレッドＩＤ、スレ
ッドのスタック・サイズ、スタック・ベース・アドレ
ス、変更された「libthread 」ルーチン８４から得られ
るスタック限度などの各スレッドに関する情報を維持す
る。ｄｂｘ ＲＴｃルーチンも漏れのチェック時に、変
更された「libthread_db」ルーチン８２から取得される
このようなスレッドごとの情報を必要とすることに留意
されたい。
【００５９】好ましい実施形態 図６を参照すると、基本デバッガ（「ｄｂｘ」）によっ
て行われるステップが示されている（６００）。デバッ
ガ・テスト・ランの開始時に、ターゲット・アプリケー
ション・オブジェクト・コードがｄｂｘの制御の下で機
械にロードされる（６０２）。ユーザはテスト・モード
を選択し（６０４）、自分がメモリ・アクセス・チェッ
クだけ（６０５）を行いたいのか、メモリ漏れの検出だ
け（６０９）を行いたいのか、あるいは両方（６０７）
を行いたいのかを示す。どの選択であっても、ｄｂｘは
モード標識６０６、６０８、６１０をセットして、先へ
進む。ｄｂｘは次いで、ターゲット・アプリケーション
がマルチスレッド・アプリケーションであるか否かを判
定する（６１２）。ターゲット・アプリケーションがマ
ルチスレッド・アプリケーションでない場合（６１
４）、ｄｂｘはシングルスレッド（すなわち、非ＭＴ）
標識をセットし（６１８）、さらに処理を行うためにＲ
ＴＣの呼出しを継続する（６３０）。ターゲット・アプ
リケーションがマルチスレッド・アプリケーションであ
る場合（６１６）、ｄｂｘは付加的なマルチスレッド・
ライブラリ「libthread_db」がまだロードされていなけ
れば、これをロードする（６２０）。ｄｂｘはマルチス
レッド・テスト標識をセットし、さらに処理を行うため
にＲＴＣの呼出しを継続する（６３０）。
て行われるステップが示されている（６００）。デバッ
ガ・テスト・ランの開始時に、ターゲット・アプリケー
ション・オブジェクト・コードがｄｂｘの制御の下で機
械にロードされる（６０２）。ユーザはテスト・モード
を選択し（６０４）、自分がメモリ・アクセス・チェッ
クだけ（６０５）を行いたいのか、メモリ漏れの検出だ
け（６０９）を行いたいのか、あるいは両方（６０７）
を行いたいのかを示す。どの選択であっても、ｄｂｘは
モード標識６０６、６０８、６１０をセットして、先へ
進む。ｄｂｘは次いで、ターゲット・アプリケーション
がマルチスレッド・アプリケーションであるか否かを判
定する（６１２）。ターゲット・アプリケーションがマ
ルチスレッド・アプリケーションでない場合（６１
４）、ｄｂｘはシングルスレッド（すなわち、非ＭＴ）
標識をセットし（６１８）、さらに処理を行うためにＲ
ＴＣの呼出しを継続する（６３０）。ターゲット・アプ
リケーションがマルチスレッド・アプリケーションであ
る場合（６１６）、ｄｂｘは付加的なマルチスレッド・
ライブラリ「libthread_db」がまだロードされていなけ
れば、これをロードする（６２０）。ｄｂｘはマルチス
レッド・テスト標識をセットし、さらに処理を行うため
にＲＴＣの呼出しを継続する（６３０）。
【００６０】ここで図７を参照すると、ＲＴＣが行うテ
スト・ステップとテスト・ルーチン「librtc.so 」が示
されている（７００）。ＲＴＣに入ると（６３０）、Ｒ
ＴＣはメモリ・アクセス状況が初期化されているかどう
かをチェックする（７０１）。初期化されている場合に
は（７０３）、制御は「librtc.so 」７０５に転送さ
れ、librtc.soはエントリ状況をチェックし（７０
２）、「malloc」または「free 」コマンドに遭遇した
結果として、メモリ状況を改訂するのかどうか（７０
６）、あるいはこれがメモリ・アクセス・チェック・エ
ントリなのかどうか（７０８）を判定する。メモリ漏れ
検出処理のためのＲＴＣルーチンへの他のエントリが図
８に示されており、これらについては後で詳述する。図
７に戻ると、ＲＴＣへのエントリが初期化エントリであ
る場合（７０４）、ターゲット・アプリケーション・プ
ログラム・プロセスにはパッチングが行われ、メモリ・
アクセス・チェックのために計装され（７１０）、メモ
リ状況アレイが図１−図３に関する基本的なＲＴＣの説
明で上記したように初期化され（７１２）、その後、Ｒ
ＴＣはｄｂｘへ戻る（７１４）。ＲＴＣのエントリがメ
モリ状況更新エントリである場合（７０６）、これがマ
ルチスレッド・アプリケーションであるかどうかについ
て、標識がテストされ（７１６）、そうでない場合には
（７１８）、メモリ状況アレイが正常に更新され（７２
６）、ｄｂｘへの復帰（７１４）が実行される。マルチ
スレッド・アプリケーションである場合（７２０）、
「libthread 」が現行スレッドＩＤを取得するために呼
び出される（７２２）。これがＲＴＣが初めてスレッド
に遭遇した場合なのであれば（７１９）、ＲＴＣはスレ
ッドＩＤ、スタック開始アドレス、スタック限度、スタ
ック・サイズ、現行スタック・ポインタ、ＲＴＣがその
時点でそのスレッドに対してＯＮ／ＯＦＦであるかを示
すフラグ、エラー・メッセージ・バッファ、スレッドが
ＲＴＣによって以前に調べられたかどうかを示すフラグ
を含むスレッドごとのデータに対して記憶域を割り当て
る（７２１）。このスレッドごとのデータはテーブルに
維持され、テーブルの各エントリは一意のスレッドに対
するデータに対応している。スレッドが作成され、破壊
されると、テーブルのエントリは動的に割り当てられ、
解放される。ＲＴＣはスレッドＩＤによってテーブルか
らこのスレッドごとのデータにアクセスする。これはテ
ーブルへのキー・インデックスとして役立つ。複数のス
レッドがＲＴＣに並行して入れることに留意されたい。
しかしながら、ＲＴＣコードのクリティカルなセクショ
ンおよびＲＴＣの共用大域データは、同期化プリミティ
ブ（ロック）によって保護される。たとえば、図７の説
明を続けると、スレッドごとのデータを取得した後（７
２４）、ＲＴＣのコードはロックされ（７２５）、他の
スレッドはメモリ状況が更新され（７２６）、ロックが
解除され（７２７）、ｄｂｘへの復帰（７１４）が実行
されるまで、入れなくなるようになる。
スト・ステップとテスト・ルーチン「librtc.so 」が示
されている（７００）。ＲＴＣに入ると（６３０）、Ｒ
ＴＣはメモリ・アクセス状況が初期化されているかどう
かをチェックする（７０１）。初期化されている場合に
は（７０３）、制御は「librtc.so 」７０５に転送さ
れ、librtc.soはエントリ状況をチェックし（７０
２）、「malloc」または「free 」コマンドに遭遇した
結果として、メモリ状況を改訂するのかどうか（７０
６）、あるいはこれがメモリ・アクセス・チェック・エ
ントリなのかどうか（７０８）を判定する。メモリ漏れ
検出処理のためのＲＴＣルーチンへの他のエントリが図
８に示されており、これらについては後で詳述する。図
７に戻ると、ＲＴＣへのエントリが初期化エントリであ
る場合（７０４）、ターゲット・アプリケーション・プ
ログラム・プロセスにはパッチングが行われ、メモリ・
アクセス・チェックのために計装され（７１０）、メモ
リ状況アレイが図１−図３に関する基本的なＲＴＣの説
明で上記したように初期化され（７１２）、その後、Ｒ
ＴＣはｄｂｘへ戻る（７１４）。ＲＴＣのエントリがメ
モリ状況更新エントリである場合（７０６）、これがマ
ルチスレッド・アプリケーションであるかどうかについ
て、標識がテストされ（７１６）、そうでない場合には
（７１８）、メモリ状況アレイが正常に更新され（７２
６）、ｄｂｘへの復帰（７１４）が実行される。マルチ
スレッド・アプリケーションである場合（７２０）、
「libthread 」が現行スレッドＩＤを取得するために呼
び出される（７２２）。これがＲＴＣが初めてスレッド
に遭遇した場合なのであれば（７１９）、ＲＴＣはスレ
ッドＩＤ、スタック開始アドレス、スタック限度、スタ
ック・サイズ、現行スタック・ポインタ、ＲＴＣがその
時点でそのスレッドに対してＯＮ／ＯＦＦであるかを示
すフラグ、エラー・メッセージ・バッファ、スレッドが
ＲＴＣによって以前に調べられたかどうかを示すフラグ
を含むスレッドごとのデータに対して記憶域を割り当て
る（７２１）。このスレッドごとのデータはテーブルに
維持され、テーブルの各エントリは一意のスレッドに対
するデータに対応している。スレッドが作成され、破壊
されると、テーブルのエントリは動的に割り当てられ、
解放される。ＲＴＣはスレッドＩＤによってテーブルか
らこのスレッドごとのデータにアクセスする。これはテ
ーブルへのキー・インデックスとして役立つ。複数のス
レッドがＲＴＣに並行して入れることに留意されたい。
しかしながら、ＲＴＣコードのクリティカルなセクショ
ンおよびＲＴＣの共用大域データは、同期化プリミティ
ブ（ロック）によって保護される。たとえば、図７の説
明を続けると、スレッドごとのデータを取得した後（７
２４）、ＲＴＣのコードはロックされ（７２５）、他の
スレッドはメモリ状況が更新され（７２６）、ロックが
解除され（７２７）、ｄｂｘへの復帰（７１４）が実行
されるまで、入れなくなるようになる。
【００６１】ＲＴＣへのエントリがメモリ・アクセス・
チェックである場合（７０８）、ＲＴＣはメモリ・アク
セスがテストされるのか、スキップされるのか（ユーザ
がテストするロケーションを指定できるのか否か）を調
べるテストを行う（７２８）。アクセス・チェックをス
キップする場合、ＲＴＣは終了する（７１４）。アクセ
ス・チェックをスキップしない場合、ＲＴＣはこれがマ
ルチスレッド・アプリケーションであるかどうかを再度
テストする（７３０）。マルチスレッド・アプリケーシ
ョンでない場合（７３４）、librtc.so は正規の（スレ
ッドなし）メモリ状況テストを行い（７４６）、何らか
のエラーがあれば、これを記録し（７５２）、終了する
（７１４）。マルチスレッド標識がｏｎであれば（７３
２）現行のスレッドＩＤが「libthread 」から取得され
る（７３６）。また、上記と同様に、これがＲＴＣによ
るこのスレッドとの最初の遭遇である場合には（７３
７）、ＲＴＣはスレッドのＩＤ、スタック開始アドレ
ス、スタック限度、スタック・サイズ、現行スタック・
ポインタ、ＲＴＣがその時点でそのスレッドに対してＯ
Ｎ／ＯＦＦであるかを示すフラグ、エラー・メッセージ
・バッファ、スレッドがＲＴＣによって以前に調べられ
たかどうかを示すフラグを含むスレッドごとのデータに
対して記憶域を割り当てる（７３９）。このスレッドご
とのデータは上述のようにテーブルに維持される。ＲＴ
Ｃのコードは次いでロックされ（７４０）、中断のない
状況チェック（７４２）が示されたロケーションに対し
て行われ、次いで、ＲＴＣのチェック・コードがロック
解除される（７４４）。メモリ・ロケーションの状況が
チェックされた後、状況が妥当性について評価され（７
４６）、妥当であれば（７４８）、ＲＴＣは終了する
（７１４）。ロケーションが無効であると判明した場合
には（７５０）、エラー・メッセージが問題のスレッド
に対するエラー・バッファに記録され（７５２）、スレ
ッドＩＤとエラーのタイプおよびロケーションを記録す
る。その後、ＲＴＣは終了する（７１４）。記録された
エラー・メッセージが通常、デバッグ作業の終了時に表
示されることに留意されたい。あるいは、これらをこれ
らに遭遇したときにユーザに対して表示することもでき
る。ユーザはデバッガ・インタフェース画面と対話する
ことによって、どのオプションを選ぶのかを指定するこ
とができる。
チェックである場合（７０８）、ＲＴＣはメモリ・アク
セスがテストされるのか、スキップされるのか（ユーザ
がテストするロケーションを指定できるのか否か）を調
べるテストを行う（７２８）。アクセス・チェックをス
キップする場合、ＲＴＣは終了する（７１４）。アクセ
ス・チェックをスキップしない場合、ＲＴＣはこれがマ
ルチスレッド・アプリケーションであるかどうかを再度
テストする（７３０）。マルチスレッド・アプリケーシ
ョンでない場合（７３４）、librtc.so は正規の（スレ
ッドなし）メモリ状況テストを行い（７４６）、何らか
のエラーがあれば、これを記録し（７５２）、終了する
（７１４）。マルチスレッド標識がｏｎであれば（７３
２）現行のスレッドＩＤが「libthread 」から取得され
る（７３６）。また、上記と同様に、これがＲＴＣによ
るこのスレッドとの最初の遭遇である場合には（７３
７）、ＲＴＣはスレッドのＩＤ、スタック開始アドレ
ス、スタック限度、スタック・サイズ、現行スタック・
ポインタ、ＲＴＣがその時点でそのスレッドに対してＯ
Ｎ／ＯＦＦであるかを示すフラグ、エラー・メッセージ
・バッファ、スレッドがＲＴＣによって以前に調べられ
たかどうかを示すフラグを含むスレッドごとのデータに
対して記憶域を割り当てる（７３９）。このスレッドご
とのデータは上述のようにテーブルに維持される。ＲＴ
Ｃのコードは次いでロックされ（７４０）、中断のない
状況チェック（７４２）が示されたロケーションに対し
て行われ、次いで、ＲＴＣのチェック・コードがロック
解除される（７４４）。メモリ・ロケーションの状況が
チェックされた後、状況が妥当性について評価され（７
４６）、妥当であれば（７４８）、ＲＴＣは終了する
（７１４）。ロケーションが無効であると判明した場合
には（７５０）、エラー・メッセージが問題のスレッド
に対するエラー・バッファに記録され（７５２）、スレ
ッドＩＤとエラーのタイプおよびロケーションを記録す
る。その後、ＲＴＣは終了する（７１４）。記録された
エラー・メッセージが通常、デバッグ作業の終了時に表
示されることに留意されたい。あるいは、これらをこれ
らに遭遇したときにユーザに対して表示することもでき
る。ユーザはデバッガ・インタフェース画面と対話する
ことによって、どのオプションを選ぶのかを指定するこ
とができる。
【００６２】ｄｂｘデバッガおよびそのＲＴＣセクショ
ンは「メモリ漏れ」を検出するために、メモリ・ロケー
ションの状況を維持する能力を有している。「メモリ漏
れ」はある時点で割り当てられ（たとえば、そのロケー
ションに対するポインタを作成することによって）、も
はやアクセスできなくなっているが、まだ解放されてい
ない（すなわち、割り当て解除されていない、他の用途
に利用できない）ロケーションと定義される。これは、
たとえば、元のロケーションを解放せずに変更されたロ
ケーションに対するポインタ、あるいはロケーションを
解放せずに終了するだけのポインタを含んでいるルーチ
ンによって生じる。このようなアクセス不能ロケーショ
ンをユーザ／開発者に通知するためにこのような事態を
追跡することは、ＲＴＣの「メモリ漏れ検出」機能の関
数である。ユーザはデバッグ作業の終了時にすべての漏
れを表示することを望んでいると指定することができ、
また、いつでも、「漏れ表示」を指定することができ
る。ここで図８を参照すると、マルチスレッド環境でメ
モリ漏れ検出を取り扱うＲＴＣの関数（８００）が示さ
れている。ＲＴＣに入った場合（６３０）、ＲＴＣはエ
ントリのタイプをチェックし（８０２）、エントリがす
べての漏れを報告するのか（８０４）、漏れを直ちに報
告するのか（８１０）、メモリ漏れ状況を変更するのか
（８０８）、あるいはメモリ状況領域を初期化するのか
（８０６）を判定する。初期化エントリである場合（８
０６）、漏れを追跡するためにＲＴＣが使用するメモリ
領域が初期化され（８１２）、プログラムは終了する
（８１６）。エントリがメモリ漏れ状況領域を更新する
ものである場合（８０８）、状況が更新され（８１
８）、プログラムは終了する（８１６）。他の２つのエ
ントリ、すなわち、すべての漏れの報告（８０４）およ
び漏れの即時報告（８１０）は同じ態様で機能するが、
唯一の相違は前者がデバッグ作業の終了時に行われるに
対し、後者が任意の時点で行えることである。両方のエ
ントリはスレッドがまだ活動しているかどうかをチェッ
クしようとする（８２０）。通常、デバッグ作業の終了
時には、すべてのスレッドが完了していなければならな
い。スレッドがまったく活動していない場合には（８２
２）、漏れメモリ状況がチェックされ、すべての指定さ
れた漏れが報告され（８２６）、プログラムは終了する
（８１６）。次いで、ｄｂｘはlibthread_dbを使用し
て、何らかのスレッドが依然活動しているかどうかを判
定し（８２４）（libthread_dbがすべての活動スレッド
をリストする関数を備えており、かつｄｂｘがユーザ・
プロセスによって作成されたすべてのスレッドのこのリ
ストを維持するので）、次いで、ＲＴＣは活動スレッド
のこのリストから次の活動スレッドＩＤを取得し（８２
８）、そのスレッドＩＤを使用して、このスレッドのレ
ジスタ・セット、スレッド・スタック・サイズ、および
スレッド開始アドレスをlibthread_dbから取得し、これ
らをチェックして、これらが以前に割り当てられたメモ
リに対するポインタを含んでいるかどうかを調べ、含ん
でいる場合には、漏れメモリ状況が更新され、見つかっ
たポインタに対応するロケーションを「漏れなし」と指
定する（８３０）。ＲＴＣプログラムは次いで、他に残
っている活動スレッドがあるかどうかをチェックし（８
３２）、存在している場合には、ステップ８２８および
８３０を繰り返す。すべての活動スレッドがチェックさ
れたら（８３６）、メモリ漏れ状況領域をチェックし、
すべての漏れを報告し（８２６）、プログラムは終了す
る（８１６）。
ンは「メモリ漏れ」を検出するために、メモリ・ロケー
ションの状況を維持する能力を有している。「メモリ漏
れ」はある時点で割り当てられ（たとえば、そのロケー
ションに対するポインタを作成することによって）、も
はやアクセスできなくなっているが、まだ解放されてい
ない（すなわち、割り当て解除されていない、他の用途
に利用できない）ロケーションと定義される。これは、
たとえば、元のロケーションを解放せずに変更されたロ
ケーションに対するポインタ、あるいはロケーションを
解放せずに終了するだけのポインタを含んでいるルーチ
ンによって生じる。このようなアクセス不能ロケーショ
ンをユーザ／開発者に通知するためにこのような事態を
追跡することは、ＲＴＣの「メモリ漏れ検出」機能の関
数である。ユーザはデバッグ作業の終了時にすべての漏
れを表示することを望んでいると指定することができ、
また、いつでも、「漏れ表示」を指定することができ
る。ここで図８を参照すると、マルチスレッド環境でメ
モリ漏れ検出を取り扱うＲＴＣの関数（８００）が示さ
れている。ＲＴＣに入った場合（６３０）、ＲＴＣはエ
ントリのタイプをチェックし（８０２）、エントリがす
べての漏れを報告するのか（８０４）、漏れを直ちに報
告するのか（８１０）、メモリ漏れ状況を変更するのか
（８０８）、あるいはメモリ状況領域を初期化するのか
（８０６）を判定する。初期化エントリである場合（８
０６）、漏れを追跡するためにＲＴＣが使用するメモリ
領域が初期化され（８１２）、プログラムは終了する
（８１６）。エントリがメモリ漏れ状況領域を更新する
ものである場合（８０８）、状況が更新され（８１
８）、プログラムは終了する（８１６）。他の２つのエ
ントリ、すなわち、すべての漏れの報告（８０４）およ
び漏れの即時報告（８１０）は同じ態様で機能するが、
唯一の相違は前者がデバッグ作業の終了時に行われるに
対し、後者が任意の時点で行えることである。両方のエ
ントリはスレッドがまだ活動しているかどうかをチェッ
クしようとする（８２０）。通常、デバッグ作業の終了
時には、すべてのスレッドが完了していなければならな
い。スレッドがまったく活動していない場合には（８２
２）、漏れメモリ状況がチェックされ、すべての指定さ
れた漏れが報告され（８２６）、プログラムは終了する
（８１６）。次いで、ｄｂｘはlibthread_dbを使用し
て、何らかのスレッドが依然活動しているかどうかを判
定し（８２４）（libthread_dbがすべての活動スレッド
をリストする関数を備えており、かつｄｂｘがユーザ・
プロセスによって作成されたすべてのスレッドのこのリ
ストを維持するので）、次いで、ＲＴＣは活動スレッド
のこのリストから次の活動スレッドＩＤを取得し（８２
８）、そのスレッドＩＤを使用して、このスレッドのレ
ジスタ・セット、スレッド・スタック・サイズ、および
スレッド開始アドレスをlibthread_dbから取得し、これ
らをチェックして、これらが以前に割り当てられたメモ
リに対するポインタを含んでいるかどうかを調べ、含ん
でいる場合には、漏れメモリ状況が更新され、見つかっ
たポインタに対応するロケーションを「漏れなし」と指
定する（８３０）。ＲＴＣプログラムは次いで、他に残
っている活動スレッドがあるかどうかをチェックし（８
３２）、存在している場合には、ステップ８２８および
８３０を繰り返す。すべての活動スレッドがチェックさ
れたら（８３６）、メモリ漏れ状況領域をチェックし、
すべての漏れを報告し（８２６）、プログラムは終了す
る（８１６）。
【００６３】マルチスレッド・プログラムの実行時チェ
ックシステム（ＲＴＣ／ＭＴ）の好ましい実施形態を、
特定の手順、構造（典型的なマルチプロセッシング・ハ
ードウェア構成など）、テストにより、またＳｕｎ実行
時チェック（ＲＴＣ）機能の特定の実施形態を備えてお
り、「libthread」および「libthread_db」などの特定
のＳｕｎライブラリ・ルーチンを使用するＳｕｎ ＳＰ
ＡＲＣＷｏｒｋｓデバッガの枠組みで説明した。しかし
ながら、当分野の技術者にはこれらの機能がすべて、マ
ルチスレッド・アプリケーションを実行することのでき
る各種のオペレーティング・システムを備えた各種のユ
ニプロセッシング・システムまたはマルチプロセッシン
グ・システムで実現できることが認識されよう。同様
に、他の同等なテスト・システムは現行のスレッドＩＤ
を取得し、その後、スレッドのスタック、エラー・バッ
ファ、およびレジスタ・セットを取得するために「libt
hread 」および「libthread_db」などのライブラリを使
用せず、その代わり、スタック・サイズが予期したサイ
ズよりも大きくなるかどうかを調べるために、スレッド
のスタック・サイズをテストするなどの、スレッドの存
在を把握するための他の装置を使用することもできる。
このような見かけ上大きなスタック・サイズを新しいス
タック、したがって新しいスレッドの標識として使用す
ることができる。このようなすべての同等な方式は本明
細書で開示し、首記の特許請求の範囲に記載した好まし
い実施形態の同等物とみなされる。
ックシステム（ＲＴＣ／ＭＴ）の好ましい実施形態を、
特定の手順、構造（典型的なマルチプロセッシング・ハ
ードウェア構成など）、テストにより、またＳｕｎ実行
時チェック（ＲＴＣ）機能の特定の実施形態を備えてお
り、「libthread」および「libthread_db」などの特定
のＳｕｎライブラリ・ルーチンを使用するＳｕｎ ＳＰ
ＡＲＣＷｏｒｋｓデバッガの枠組みで説明した。しかし
ながら、当分野の技術者にはこれらの機能がすべて、マ
ルチスレッド・アプリケーションを実行することのでき
る各種のオペレーティング・システムを備えた各種のユ
ニプロセッシング・システムまたはマルチプロセッシン
グ・システムで実現できることが認識されよう。同様
に、他の同等なテスト・システムは現行のスレッドＩＤ
を取得し、その後、スレッドのスタック、エラー・バッ
ファ、およびレジスタ・セットを取得するために「libt
hread 」および「libthread_db」などのライブラリを使
用せず、その代わり、スタック・サイズが予期したサイ
ズよりも大きくなるかどうかを調べるために、スレッド
のスタック・サイズをテストするなどの、スレッドの存
在を把握するための他の装置を使用することもできる。
このような見かけ上大きなスタック・サイズを新しいス
タック、したがって新しいスレッドの標識として使用す
ることができる。このようなすべての同等な方式は本明
細書で開示し、首記の特許請求の範囲に記載した好まし
い実施形態の同等物とみなされる。
【図１】 動的パッチングを使用した実行時エラー・チ
ェック・システムのコンピュータ・ブロック図である。
ェック・システムのコンピュータ・ブロック図である。
【図２】 実行時エラー・チェックの動的パッチングの
一般的な流れ図である。
一般的な流れ図である。
【図３】 実行時エラー・チェック方法の動的パッチン
グの図である。
グの図である。
【図４】 典型的なマルチプロセッサ・システムの構成
を示す図である。
を示す図である。
【図５】 マルチプロセッシング環境に適合させるため
にユニプロセッサの実行時・チェック・システムに必要
な一般的な変更を示す図である。
にユニプロセッサの実行時・チェック・システムに必要
な一般的な変更を示す図である。
【図６】 マルチプロセッシングに適合するため基本デ
バッガによって行われるステップのブロック図である。
バッガによって行われるステップのブロック図である。
【図７】 メモリ・アクセス・チェックを行う場合にマ
ルチプロセッシングに適合するため実行時チェッカ（Ｒ
ＴＣ）および基本デバッガの「librtc.so 」部分によっ
て行われるステップのブロック図である。
ルチプロセッシングに適合するため実行時チェッカ（Ｒ
ＴＣ）および基本デバッガの「librtc.so 」部分によっ
て行われるステップのブロック図である。
【図８】 メモリ漏れチェックを行う場合にマルチプロ
セッシングに適合するためＲＴＣおよび「librtc.so 」
モジュールの基本デバッガによって行われるステップの
ブロック図である。
セッシングに適合するためＲＴＣおよび「librtc.so 」
モジュールの基本デバッガによって行われるステップの
ブロック図である。
【符号の説明】 ３０１ ディスク ３０２ プログラム ３０４ 入出力装置 ３０５ メモリ ３０６ ＣＰＵ ３０７ デバッガ ３１０ モジュール ４１０、４１２、４１４ プロセッサ
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジョン・エイ・マサミツ アメリカ合衆国 94550 カリフォルニア 州・リバーモア・クリーク ロード・1873
Claims (11)
- 【請求項１】 メモリ、クロック、１つまたは複数の中
央演算処理装置（ＣＰＵ）を有しており、かつ前記メモ
リ内にプログラム機械命令を有しており、またマルチス
レッド・オペレーティング・システムも有しているコン
ピュータ・システムで実行可能な、マルチスレッド・タ
ーゲット・プログラムのメモリ・アクセス・チェック方
法において、 メモリ・アクセス・チェック機能を有しており、前記マ
ルチスレッド・オペレーティング・システムと関連して
作動するマルチスレッドに安全（「ＭＴ安全」）なデバ
ッガ・プログラムを設けるステップと、 少なくともメモリ・ロケーションが割当て状態にあるの
か、割当て解除状態にあるのかを示し、前記割当て状態
がコンピュータ・プログラムによって割り当てられたメ
モリ・ロケーションに対応しており、前記割当て解除状
態が前記コンピュータ・プログラムによって割り当てら
れていないメモリ・ロケーションに対応しており、前記
ＭＴ安全デバッガ・プログラムによって維持される、前
記メモリ内のメモリ・ロケーションに関するメモリ状況
情報を与えるステップとを備え、前記コンピュータ・シ
ステムの制御の下で、前記ＭＴ安全デバッガ・プログラ
ムが前記マルチスレッド・ターゲット・プログラムによ
ってアクセスされる各メモリ・ロケーションについて前
記メモリ状況情報をチェックするメモリ・アクセス・チ
ェック方法。 - 【請求項２】 アクセスされた前記メモリ・ロケーショ
ンに関する前記状況情報が割当て解除状態を示した場合
に、エラーを報告する付加ステップを含んでいる請求項
１に記載の方法。 - 【請求項３】 少なくともメモリ・ロケーションがアク
セス不能状態であるか否かを示し、前記アクセス不能状
態が割当て状態であるが、前記マルチスレッド・ターゲ
ット・コンピュータ・プログラムではアクセス不能であ
るメモリ・ロケーションに対応しており、前記ＭＴ安全
デバッガ・プログラムによって維持されている、前記メ
モリ内のメモリ・ロケーションに関するメモリ漏れ状況
情報を与える付加ステップを含んでおり、 前記コンピュータ・システムの制御の下で、前記ＭＴ安
全デバッガ・プログラムが前記メモリ漏れ状況情報をチ
ェックし、前記アクセス不能状態と指定された前記メモ
リ・ロケーションを報告する請求項１に記載の方法。 - 【請求項４】 メモリ、クロック、１つまたは複数の中
央演算処理装置（ＣＰＵ）を有しており、かつ前記メモ
リ内にプログラム機械命令を有しており、またマルチス
レッド・オペレーティング・システムも有しているコン
ピュータ・システムで実行可能な、マルチスレッド・タ
ーゲット・プログラムのメモリ漏れチェック方法におい
て、 メモリ漏れチェック機能を有しており、前記マルチスレ
ッド・オペレーティング・システムと関連して作動する
マルチスレッドに安全（「ＭＴ安全」）なデバッガ・プ
ログラムを設けるステップと、 少なくともメモリ・ロケーションがアクセス不能状態で
あるか否かを示し、そのアクセス不能状態が割当て状態
であるが、前記マルチスレッド・ターゲット・コンピュ
ータ・プログラムではアクセス不能であるメモリ・ロケ
ーションに対応しており、前記ＭＴ安全デバッガ・プロ
グラムによって維持される、前記メモリ内のメモリ・ロ
ケーションに関するメモリ漏れ状況情報を与えるステッ
プと、 前記コンピュータ・システムの制御の下で、前記メモリ
漏れ状況情報をチェックするステップとからなるメモリ
漏れチェック方法。 - 【請求項５】 メモリ、クロック、１つまたは複数の中
央演算処理装置（ＣＰＵ）を有しており、かつ前記メモ
リ内にプログラム機械命令を有しており、また前記メモ
リにロードされるマルチスレッド・オペレーティング・
システムも有している、マルチスレッド・ターゲット・
プログラムのメモリ・アクセスをチェックするコンピュ
ータ・システムにおいて、 メモリ・アクセス・チェック機能を有しており、前記メ
モリにロードされ、前記マルチスレッド・オペレーティ
ング・システムに結合されるマルチスレッドに安全
（「ＭＴ安全」）なデバッガ・プログラムと、 前記ＭＴ安全デバッガの制御の下で前記メモリにロード
されるマルチスレッド・ターゲット・プログラムと、 前記マルチスレッド・ターゲット・プログラムをテスト
するために前記マルチスレッド・オペレーティング・シ
ステムおよび前記ＭＴ安全デバッガを実行する１つまた
は複数のＣＰＵとを有し、前記ＭＴ安全デバッガが前記
メモリ内のメモリ・ロケーションに関するメモリ状況情
報をもたらす第１の機械実行可能機構を有しており、前
記メモリ状況情報が少なくともメモリ・ロケーションが
割当て状態にあるのか、割当て解除状態にあるのかを示
し、前記割当て状態がコンピュータ・プログラムによっ
て割り当てられたメモリ・ロケーションに対応してお
り、前記割当て解除状態が前記コンピュータ・プログラ
ムによって割り当てられていないメモリ・ロケーション
に対応しており、前記状況情報が前記マルチスレッド・
ターゲット・プログラムの前記テスト中に前記ＭＴ安全
デバッガ・プログラムによって維持されており、 前記ＭＴ安全デバッガが前記マルチスレッド・ターゲッ
ト・プログラムによってアクセスされた各メモリ・ロケ
ーションに関する前記メモリ状況情報をチェックする第
２の機械実行可能機構を有しているメモリ・アクセスを
チェックするコンピュータ・システム。 - 【請求項６】 前記のアクセスされたメモリ・ロケーシ
ョンに関する前記状況情報が割当て解除状態である場合
に、エラーを報告する報告機構をさらに含んでいる請求
項５に記載のコンピュータ・システム。 - 【請求項７】 少なくともメモリ・ロケーションがアク
セス不能状態であるか否かを示し、前記アクセス不能状
態が割当て状態であるが、前記コンピュータ・プログラ
ムではアクセス不能であるメモリ・ロケーションに対応
しており、前記ＭＴ安全デバッガ・プログラムによって
維持される、前記メモリ内のメモリ・ロケーションに関
するメモリ漏れ状況情報を与える前記ＭＴ安全デバッガ
に結合された第３の機械実行可能機構と、 前記メモリ漏れ状況情報をチェックする、前記ＭＴ安全
デバッガに結合された第４の機械実行可能機構とをさら
に含んでいる請求項５に記載のコンピュータ・システ
ム。 - 【請求項８】 メモリ、クロック、１つまたは複数の中
央演算処理装置（ＣＰＵ）を有しており、かつ前記メモ
リ内にプログラム機械命令を有しており、また前記メモ
リにロードされるマルチスレッド・オペレーティング・
システムも有しているコンピュータ・システムにおい
て、 メモリ漏れチェック機能を有しており、前記メモリにロ
ードされ、前記マルチスレッド・オペレーティング・シ
ステムに結合されるマルチスレッドに安全（「ＭＴ安
全」）なデバッガ・プログラムと、 前記ＭＴ安全デバッガの制御の下で前記メモリにロード
されるマルチスレッド・ターゲット・プログラムと、 前記マルチスレッド・ターゲット・プログラムをテスト
するために前記マルチスレッド・オペレーティング・シ
ステムおよび前記ＭＴ安全デバッガを実行する１つまた
は複数のＣＰＵとからなり、前記ＭＴ安全デバッガが前
記メモリ内のメモリ・ロケーションに関するメモリ漏れ
状況情報をもたらす第１の機械実行可能機構を有してお
り、前記メモリ漏れ状況情報は少なくともメモリ・ロケ
ーションがアクセス不能状態にあるのか否かを示し、前
記アクセス不能状態が割当て状態であるが、前記マルチ
スレッド・ターゲット・コンピュータ・プログラムでは
アクセス不能であるメモリ・ロケーションに対応してお
り、前記マルチスレッド・ターゲット・プログラムのテ
スト中に前記ＭＴ安全デバッガ・プログラムによって維
持されており、 前記ＭＴ安全デバッガが前記マルチスレッド・ターゲッ
ト・プログラムによってアクセスされた各メモリ・ロケ
ーションに関する前記メモリ漏れ状況情報をチェックす
る第２の機械実行可能機構を有しているコンピュータ・
システム。 - 【請求項９】 メモリ漏れと指定されるアクセス不能状
態と指定されている前記メモリ・ロケーションを報告す
る報告機構をさらに含んでいる請求項８に記載のコンピ
ュータ・システム。 - 【請求項１０】 マルチスレッド・ターゲット・プログ
ラムを実行時チェックする（「ＲＴＣ」）マルチスレッ
ドに安全（「ＭＴ安全」）機構をもたらすデバッガにお
いて、 前記メモリ状況情報が少なくともメモリ・ロケーション
が割当て状態にあるのか、割当て解除状態にあるのかを
示し、前記割当て状態がコンピュータ・プログラムによ
って割り当てられたメモリ・ロケーションに対応してお
り、前記割当て解除状態が前記コンピュータ・プログラ
ムによって割り当てられていないメモリ・ロケーション
に対応しており、前記マルチスレッド・ターゲット・プ
ログラムのテスト中に前記ＭＴ安全機構によって維持さ
れ、前記コンピュータ・システム内のメモリ・ロケーシ
ョンの状況を維持する第１の機械実行可能構造と、 前記マルチスレッド・ターゲット・プログラムによって
アクセスされる各メモリ・ロケーションに関する前記メ
モリ状況情報をチェックし、報告する第２の機械実行可
能構造とからなるデバッガ。 - 【請求項１１】 アクセスされた前記メモリ・ロケーシ
ョンに関する前記状況情報が割当て解除状態を示した場
合に、エラーを報告する報告機構をさらに含んでおり、
前記第２の機械実行可能構造が前記ＭＴ安全機構の制御
下にある、請求項１０に記載のデバッガ。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US38488495A | 1995-02-07 | 1995-02-07 | |
| US08/384884 | 1995-02-07 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH0922370A true JPH0922370A (ja) | 1997-01-21 |
Family
ID=23519153
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP8044104A Pending JPH0922370A (ja) | 1995-02-07 | 1996-02-07 | マルチスレッド・ターゲット・プログラムのメモリ・アクセス・チェック方法及び装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US5953530A (ja) |
| EP (1) | EP0729097A1 (ja) |
| JP (1) | JPH0922370A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000122882A (ja) * | 1998-10-20 | 2000-04-28 | Matsushita Electric Ind Co Ltd | マルチスレッドプロセッサおよびデバッグ装置 |
Families Citing this family (154)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6173309B1 (en) * | 1997-02-20 | 2001-01-09 | Hewlett-Packard Company | Null thread library and thread abstraction interface |
| US6189140B1 (en) * | 1997-04-08 | 2001-02-13 | Advanced Micro Devices, Inc. | Debug interface including logic generating handshake signals between a processor, an input/output port, and a trace logic |
| US6314530B1 (en) | 1997-04-08 | 2001-11-06 | Advanced Micro Devices, Inc. | Processor having a trace access instruction to access on-chip trace memory |
| DE69801332T2 (de) * | 1997-09-25 | 2002-05-23 | British Telecommunications P.L.C., London | Speicherzuordnung |
| US6938245B1 (en) | 1997-10-29 | 2005-08-30 | Veritas Operating Corporation | Interactive debugging system with debug data base system |
| EP1423792A4 (en) * | 1997-10-29 | 2009-05-27 | Symantec Operating Corp | INTERACTIVE ERROR CORRECTION SYSTEM WITH ERROR CORRECTION DATA BASE SYSTEM |
| US6516354B2 (en) | 1997-12-18 | 2003-02-04 | Sun Microsystems, Inc. | Method and apparatus for efficient representation of variable length identifiers in a distributed object system |
| US6405264B1 (en) | 1997-12-18 | 2002-06-11 | Sun Microsystems, Inc. | Marshaling and unmarshaling framework for supporting filters in a distributed object system |
| US6510460B1 (en) * | 1997-12-18 | 2003-01-21 | Sun Microsystems, Inc. | Method and apparatus for enforcing locking invariants in multi-threaded systems |
| US6249803B1 (en) | 1997-12-18 | 2001-06-19 | Sun Microsystems, Inc. | Method and apparatus for executing code during method invocation |
| US6360220B1 (en) * | 1998-08-04 | 2002-03-19 | Microsoft Corporation | Lock-free methods and systems for accessing and storing information in an indexed computer data structure having modifiable entries |
| US6594701B1 (en) | 1998-08-04 | 2003-07-15 | Microsoft Corporation | Credit-based methods and systems for controlling data flow between a sender and a receiver with reduced copying of data |
| US6321276B1 (en) | 1998-08-04 | 2001-11-20 | Microsoft Corporation | Recoverable methods and systems for processing input/output requests including virtual memory addresses |
| US6952827B1 (en) * | 1998-11-13 | 2005-10-04 | Cray Inc. | User program and operating system interface in a multithreaded environment |
| US6862635B1 (en) * | 1998-11-13 | 2005-03-01 | Cray Inc. | Synchronization techniques in a multithreaded environment |
| US6480818B1 (en) * | 1998-11-13 | 2002-11-12 | Cray Inc. | Debugging techniques in a multithreaded environment |
| US6314471B1 (en) * | 1998-11-13 | 2001-11-06 | Cray Inc. | Techniques for an interrupt free operating system |
| GB9825102D0 (en) * | 1998-11-16 | 1999-01-13 | Insignia Solutions Plc | Computer system |
| US6249288B1 (en) * | 1998-12-14 | 2001-06-19 | Ati International Srl | Multi thread display controller |
| US6430676B1 (en) | 1998-12-23 | 2002-08-06 | Cray Inc. | Method and system for calculating instruction lookahead |
| US6321379B1 (en) | 1998-12-23 | 2001-11-20 | Cray Inc. | Method and system for target register allocation |
| US6230313B1 (en) | 1998-12-23 | 2001-05-08 | Cray Inc. | Parallelism performance analysis based on execution trace information |
| US6665688B1 (en) | 1998-12-23 | 2003-12-16 | Cray Inc. | Method and system for automatically regenerating data on-demand |
| US6415433B1 (en) | 1998-12-23 | 2002-07-02 | Cray Inc. | Method and system for identifying locations to move portions of the computer program |
| US6353829B1 (en) | 1998-12-23 | 2002-03-05 | Cray Inc. | Method and system for memory allocation in a multiprocessing environment |
| US6957436B1 (en) * | 1999-01-29 | 2005-10-18 | Iona Technologies, Plc | Method and system for multi-threaded object loading and unloading |
| US6587967B1 (en) | 1999-02-22 | 2003-07-01 | International Business Machines Corporation | Debugger thread monitor |
| US6378125B1 (en) * | 1999-02-22 | 2002-04-23 | International Business Machines Corporation | Debugger thread identification points |
| US6378124B1 (en) * | 1999-02-22 | 2002-04-23 | International Business Machines Corporation | Debugger thread synchronization control points |
| WO2000054385A1 (en) * | 1999-03-10 | 2000-09-14 | Preview Systems, Inc. | User transparent software malfunction detection and reporting |
| US6874144B1 (en) * | 1999-04-05 | 2005-03-29 | International Business Machines Corporation | System, method, and program for implementing priority inheritance in an operating system |
| US6938147B1 (en) * | 1999-05-11 | 2005-08-30 | Sun Microsystems, Inc. | Processor with multiple-thread, vertically-threaded pipeline |
| US6507862B1 (en) * | 1999-05-11 | 2003-01-14 | Sun Microsystems, Inc. | Switching method in a multi-threaded processor |
| US7137105B2 (en) * | 1999-05-12 | 2006-11-14 | Wind River Systems, Inc. | Dynamic software code instrumentation method and system |
| US6405326B1 (en) * | 1999-06-08 | 2002-06-11 | International Business Machines Corporation Limited | Timing related bug detector method for detecting data races |
| FR2794876B1 (fr) * | 1999-06-10 | 2001-11-02 | Bull Sa | Procede de reconfiguration d'un systeme de traitement de l'information sur detection de defaillance d'un composant |
| US6598177B1 (en) * | 1999-10-01 | 2003-07-22 | Stmicroelectronics Ltd. | Monitoring error conditions in an integrated circuit |
| US6591413B1 (en) * | 1999-10-07 | 2003-07-08 | International Business Machines Corporation | Method and apparatus in a data processing system for faster notification of errors in a software build |
| US7865883B1 (en) | 1999-11-12 | 2011-01-04 | Oracle America, Inc. | Parallel and asynchronous debugger and debugging method for multi-threaded programs |
| AU2612501A (en) * | 1999-12-30 | 2001-07-16 | Computer Associates Think, Inc. | System and method for device failure recognition |
| US7010781B1 (en) * | 2000-02-15 | 2006-03-07 | Sun Microsystems, Inc. | Methods and apparatus for managing debugging I/O |
| US6658650B1 (en) * | 2000-02-18 | 2003-12-02 | International Business Machines Corporation | Service entry point for use in debugging multi-job computer programs |
| US6523141B1 (en) * | 2000-02-25 | 2003-02-18 | Sun Microsystems, Inc. | Method and apparatus for post-mortem kernel memory leak detection |
| US6634020B1 (en) | 2000-03-24 | 2003-10-14 | International Business Machines Corporation | Uninitialized memory watch |
| US7228346B1 (en) | 2000-04-21 | 2007-06-05 | Sun Microsystems, Inc. | IDL event and request formatting for corba gateway |
| US7010586B1 (en) | 2000-04-21 | 2006-03-07 | Sun Microsystems, Inc. | System and method for event subscriptions for CORBA gateway |
| US6915324B1 (en) | 2000-04-21 | 2005-07-05 | Sun Microsystems, Inc. | Generic and dynamic mapping of abstract syntax notation (ASN1) to and from interface definition language for network management |
| US6813770B1 (en) | 2000-04-21 | 2004-11-02 | Sun Microsystems, Inc. | Abstract syntax notation to interface definition language converter framework for network management |
| US7779390B1 (en) * | 2000-04-21 | 2010-08-17 | Oracle America, Inc. | Thread-safe remote debugger |
| US6839748B1 (en) | 2000-04-21 | 2005-01-04 | Sun Microsystems, Inc. | Synchronous task scheduler for corba gateway |
| US7206843B1 (en) | 2000-04-21 | 2007-04-17 | Sun Microsystems, Inc. | Thread-safe portable management interface |
| US7478403B1 (en) | 2000-04-21 | 2009-01-13 | Sun Microsystems, Inc. | Secure access to managed network objects using a configurable platform-independent gateway providing individual object-level access control |
| US7783720B1 (en) | 2000-04-21 | 2010-08-24 | Oracle America, Inc. | CORBA metadata gateway to telecommunications management network |
| US6950935B1 (en) | 2000-04-21 | 2005-09-27 | Sun Microsystems, Inc. | Pluggable authentication modules for telecommunications management network |
| US6857085B1 (en) * | 2000-05-15 | 2005-02-15 | Microsoft Corporation | Method and system for handling an unexpected exception generated by an application |
| DE10030988A1 (de) * | 2000-06-30 | 2002-01-10 | Bosch Gmbh Robert | Elektronisches System zur Entwicklung von Software und ein Verfahren zum Eingriff auf interne Daten der Software |
| US6748556B1 (en) * | 2000-08-15 | 2004-06-08 | International Business Machines Corporation | Changing the thread capacity of a multithreaded computer processor |
| US6681345B1 (en) * | 2000-08-15 | 2004-01-20 | International Business Machines Corporation | Field protection against thread loss in a multithreaded computer processor |
| US6671827B2 (en) * | 2000-12-21 | 2003-12-30 | Intel Corporation | Journaling for parallel hardware threads in multithreaded processor |
| GB0104764D0 (en) * | 2001-02-24 | 2001-04-18 | Ibm | Method apparatus and computer program product for controlling access to a res urce |
| EP1237080A1 (de) * | 2001-03-02 | 2002-09-04 | Siemens Aktiengesellschaft | Überprüfung eines Computersystems auf gesperrte Speicherbereiche nach einem Abbruch eines Prozesses |
| US7093249B2 (en) * | 2001-03-02 | 2006-08-15 | National Instruments Corporation | System and method for synchronizing execution of a test sequence |
| US6971084B2 (en) * | 2001-03-02 | 2005-11-29 | National Instruments Corporation | System and method for synchronizing execution of a batch of threads |
| US6754850B2 (en) * | 2001-03-02 | 2004-06-22 | National Instruments Corporation | System and method for performing batch synchronization for a test sequence |
| US7469403B2 (en) * | 2001-04-19 | 2008-12-23 | International Business Machines Corporation | Static detection of a datarace condition for multithreaded object-oriented applications |
| US6851074B2 (en) * | 2001-04-30 | 2005-02-01 | Hewlett-Packard Development Company | System and method for recovering from memory failures in computer systems |
| US7013460B2 (en) * | 2001-05-15 | 2006-03-14 | Hewlett-Packard Development Company, L.P. | Specifying an invariant property (range of addresses) in the annotation in source code of the computer program |
| US7228175B2 (en) | 2002-05-15 | 2007-06-05 | Cardiac Pacemakers, Inc. | Cardiac rhythm management systems and methods using acoustic contractility indicator |
| EP1398948B1 (en) | 2002-09-13 | 2013-11-06 | Ricoh Company, Ltd. | Image forming apparatus, methods used therein and a computer readable storage medium |
| US7065676B1 (en) * | 2002-12-27 | 2006-06-20 | Unisys Corporation | Multi-threaded memory management test system with feedback to adjust input parameters in response to performance |
| US7200542B1 (en) * | 2003-02-21 | 2007-04-03 | Hewlett-Packard Development Company, L.P. | Method and apparatus for biased identification of potential data sharing locations |
| US20050015672A1 (en) * | 2003-06-25 | 2005-01-20 | Koichi Yamada | Identifying affected program threads and enabling error containment and recovery |
| US7900092B2 (en) * | 2003-07-11 | 2011-03-01 | Computer Associates Think, Inc. | Kernel-level method of flagging problems in applications |
| DE10349200A1 (de) * | 2003-10-23 | 2005-05-25 | Daimlerchrysler Ag | System und Verfahren zur Überwachung und Verwaltung prozessinterner Speicher einer Prozessausführungseinheit |
| US7140023B2 (en) * | 2003-10-31 | 2006-11-21 | Intel Corporation | Symbolic buffer allocation in local cache at a network processing element |
| CN100470656C (zh) * | 2003-10-31 | 2009-03-18 | 宇田控股有限公司 | 摆动时钟信号的产生方法和产生装置 |
| US7324112B1 (en) | 2004-04-12 | 2008-01-29 | Nvidia Corporation | System and method for processing divergent samples in a programmable graphics processing unit |
| US7477255B1 (en) * | 2004-04-12 | 2009-01-13 | Nvidia Corporation | System and method for synchronizing divergent samples in a programmable graphics processing unit |
| US7487321B2 (en) * | 2004-04-19 | 2009-02-03 | Cisco Technology, Inc. | Method and system for memory leak detection |
| US7930491B1 (en) | 2004-04-19 | 2011-04-19 | Cisco Technology, Inc. | Memory corruption detection system and method using contingency analysis regulation |
| US7293142B1 (en) | 2004-04-19 | 2007-11-06 | Cisco Technology, Inc. | Memory leak detection system and method using contingency analysis |
| US7945900B2 (en) * | 2004-04-29 | 2011-05-17 | Marvell International Ltd. | Debugging tool for debugging multi-threaded programs |
| US7665133B2 (en) * | 2004-06-12 | 2010-02-16 | Toshbia Tec Kabushiki Kaisha | System and method for monitoring processing in a document processing peripheral |
| GB0418306D0 (en) * | 2004-08-17 | 2004-09-15 | Ibm | Debugging an application process at runtime |
| US20060048128A1 (en) * | 2004-09-01 | 2006-03-02 | Roth Steven T | Module preparation scripts |
| US7685574B2 (en) * | 2004-09-29 | 2010-03-23 | Microsoft Corporation | Constrained execution regions |
| US7506325B2 (en) * | 2004-10-07 | 2009-03-17 | International Business Machines Corporation | Partitioning processor resources based on memory usage |
| US7539833B2 (en) * | 2004-12-06 | 2009-05-26 | International Business Machines Corporation | Locating wasted memory in software by identifying unused portions of memory blocks allocated to a program |
| CN100389403C (zh) * | 2005-04-07 | 2008-05-21 | 华为技术有限公司 | 内存泄漏检测及恢复的方法 |
| US20070006166A1 (en) * | 2005-06-20 | 2007-01-04 | Seagate Technology Llc | Code coverage for an embedded processor system |
| WO2007028227A1 (en) * | 2005-09-09 | 2007-03-15 | Ibm Canada Limited - Ibm Canada Limitee | Integrating different programming language debug tools for observing thread execution |
| US20070198816A1 (en) * | 2005-11-10 | 2007-08-23 | Chuan-Po Ling | Emulation system for a single-chip multiple-microcontroller and emulation method thereof |
| US8402443B2 (en) * | 2005-12-12 | 2013-03-19 | dyna Trace software GmbH | Method and system for automated analysis of the performance of remote method invocations in multi-tier applications using bytecode instrumentation |
| US7730453B2 (en) * | 2005-12-13 | 2010-06-01 | Microsoft Corporation | Runtime detection for invalid use of zero-length memory allocations |
| US7793263B2 (en) * | 2006-02-02 | 2010-09-07 | International Business Machines Corporation | Decision support tool for interleaving review software testing |
| US8516444B2 (en) | 2006-02-23 | 2013-08-20 | International Business Machines Corporation | Debugging a high performance computing program |
| US20070226740A1 (en) * | 2006-02-28 | 2007-09-27 | Xiao-Feng Li | Method and apparatus for global breakpoint for parallel debugging on multiprocessor systems |
| US7836435B2 (en) * | 2006-03-31 | 2010-11-16 | Intel Corporation | Checking for memory access collisions in a multi-processor architecture |
| US8104019B2 (en) * | 2006-03-31 | 2012-01-24 | Microsoft Corporation | Debugging in an operating system with multiple subsystems |
| US7796527B2 (en) * | 2006-04-13 | 2010-09-14 | International Business Machines Corporation | Computer hardware fault administration |
| US20070288907A1 (en) * | 2006-05-16 | 2007-12-13 | Olivier Jeffrey V | Method and apparatus for debugging applications executed on a software relaxed consistency architecture |
| US7774741B2 (en) * | 2006-05-22 | 2010-08-10 | Microsoft Corporation | Automatically resource leak diagnosis and detecting process within the operating system |
| DE102006029138A1 (de) | 2006-06-22 | 2007-12-27 | Dspace Digital Signal Processing And Control Engineering Gmbh | Verfahren und Computerprogrammprodukt zur Detektion von Speicherlecks |
| US7500079B2 (en) * | 2006-07-31 | 2009-03-03 | Microsoft Corporation | Detection of memory leaks |
| US8533687B1 (en) | 2009-11-30 | 2013-09-10 | dynaTrade Software GmbH | Methods and system for global real-time transaction tracing |
| US8464225B2 (en) * | 2007-05-06 | 2013-06-11 | Dynatrace Software Gmbh | Method and system for adaptive, generic code instrumentation using run-time or load-time generated inheritance information for diagnosis and monitoring application performance and failure |
| US9231858B1 (en) | 2006-08-11 | 2016-01-05 | Dynatrace Software Gmbh | Completeness detection of monitored globally distributed synchronous and asynchronous transactions |
| US8516462B2 (en) * | 2006-10-09 | 2013-08-20 | International Business Machines Corporation | Method and apparatus for managing a stack |
| US20080120604A1 (en) * | 2006-11-20 | 2008-05-22 | Morris Robert P | Methods, Systems, And Computer Program Products For Providing Program Runtime Data Validation |
| US8683444B1 (en) | 2006-12-11 | 2014-03-25 | Synopsys, Inc. | System and method of debugging multi-threaded processes |
| US20080148102A1 (en) * | 2006-12-15 | 2008-06-19 | International Business Machines Corporation | Method for enhancing debugging of runtime memory access errors by using an integrated visualization tool and a runtime memory error detection tool |
| US7870358B2 (en) * | 2007-03-07 | 2011-01-11 | Lsi Corporation | Zero-penalty RAID controller memory leak detection and isolation method and system utilizing sequence numbers |
| ATE537502T1 (de) * | 2007-03-29 | 2011-12-15 | Fujitsu Ltd | Informationsverarbeitungsvorrichtung und fehlerverarbeitungsverfahren |
| US9330230B2 (en) * | 2007-04-19 | 2016-05-03 | International Business Machines Corporation | Validating a cabling topology in a distributed computing system |
| US9047412B2 (en) | 2007-05-06 | 2015-06-02 | Dynatrace Corporation | System and method for extracting instrumentation relevant inheritance relationships for a distributed, inheritance rule based instrumentation system |
| US8245209B2 (en) * | 2007-05-29 | 2012-08-14 | International Business Machines Corporation | Detecting dangling pointers and memory leaks within software |
| US8060869B1 (en) * | 2007-06-08 | 2011-11-15 | Oracle America, Inc. | Method and system for detecting memory problems in user programs |
| US7831866B2 (en) * | 2007-08-02 | 2010-11-09 | International Business Machines Corporation | Link failure detection in a parallel computer |
| US8336031B2 (en) * | 2007-09-28 | 2012-12-18 | Texas Instruments Incorporated | Method and system of performing thread scheduling |
| US8185880B2 (en) * | 2007-10-04 | 2012-05-22 | International Business Machines Corporation | Optimizing heap memory usage |
| US8739133B2 (en) | 2007-12-21 | 2014-05-27 | International Business Machines Corporation | Multi-threaded debugger support |
| US8839225B2 (en) * | 2008-01-23 | 2014-09-16 | International Business Machines Corporation | Generating and applying patches to a computer program code concurrently with its execution |
| US8776030B2 (en) * | 2008-04-09 | 2014-07-08 | Nvidia Corporation | Partitioning CUDA code for execution by a general purpose processor |
| US9678775B1 (en) * | 2008-04-09 | 2017-06-13 | Nvidia Corporation | Allocating memory for local variables of a multi-threaded program for execution in a single-threaded environment |
| GB0808576D0 (en) * | 2008-05-12 | 2008-06-18 | Xmos Ltd | Compiling and linking |
| US8266597B2 (en) * | 2008-06-16 | 2012-09-11 | International Business Machines Corporation | Dynamically patching computer code using breakpoints |
| US8478948B2 (en) * | 2008-12-04 | 2013-07-02 | Oracle America, Inc. | Method and system for efficient tracing and profiling of memory accesses during program execution |
| US20100192026A1 (en) * | 2009-01-27 | 2010-07-29 | Microsoft Corporation | Implementations of program runtime checks |
| CN101799763B (zh) * | 2009-02-10 | 2013-01-30 | 华为技术有限公司 | 内核在线补丁的方法、装置和系统 |
| US8352795B2 (en) * | 2009-02-11 | 2013-01-08 | Honeywell International Inc. | High integrity processor monitor |
| US8930907B2 (en) * | 2009-12-01 | 2015-01-06 | Microsoft Corporation | Concurrency software testing with probabilistic bounds on finding bugs |
| US8402471B2 (en) * | 2009-12-21 | 2013-03-19 | At&T Intellectual Property I, L.P. | Methods and apparatus to benchmark a computer system based on executing instructions using different numbers of threads |
| US8245081B2 (en) * | 2010-02-10 | 2012-08-14 | Vmware, Inc. | Error reporting through observation correlation |
| US8612952B2 (en) * | 2010-04-07 | 2013-12-17 | International Business Machines Corporation | Performance optimization based on data accesses during critical sections |
| US8959442B2 (en) * | 2010-06-11 | 2015-02-17 | Microsoft Corporation | Memory allocation visualization for unmanaged languages |
| US9274919B2 (en) | 2011-04-29 | 2016-03-01 | Dynatrace Software Gmbh | Transaction tracing mechanism of distributed heterogenous transactions having instrumented byte code with constant memory consumption and independent of instrumented method call depth |
| US8793661B1 (en) * | 2012-04-27 | 2014-07-29 | Google Inc. | Programmer specified conditions for raising exceptions and handling errors detected within programming code |
| US9891917B2 (en) * | 2013-03-06 | 2018-02-13 | Infineon Technologies Ag | System and method to increase lockstep core availability |
| US9483379B2 (en) * | 2013-10-15 | 2016-11-01 | Advanced Micro Devices, Inc. | Randomly branching using hardware watchpoints |
| US9779044B2 (en) | 2014-11-25 | 2017-10-03 | Nxp Usa, Inc. | Access extent monitoring for data transfer reduction |
| US9569613B2 (en) * | 2014-12-23 | 2017-02-14 | Intel Corporation | Techniques for enforcing control flow integrity using binary translation |
| US9996354B2 (en) * | 2015-01-09 | 2018-06-12 | International Business Machines Corporation | Instruction stream tracing of multi-threaded processors |
| US10402259B2 (en) | 2015-05-29 | 2019-09-03 | Nxp Usa, Inc. | Systems and methods for resource leakage recovery in processor hardware engines |
| CN106055478B (zh) * | 2016-05-31 | 2020-09-22 | 腾讯科技（深圳）有限公司 | 检测内存泄漏的方法和装置 |
| US10452287B2 (en) | 2016-06-24 | 2019-10-22 | Futurewei Technologies, Inc. | System and method for shared memory ownership using context |
| US9804952B1 (en) * | 2016-11-07 | 2017-10-31 | Red Hat, Inc. | Application debugging in a restricted container environment |
| US10635578B1 (en) | 2017-11-10 | 2020-04-28 | Amdocs Development Limited | System, method, and computer program for periodic memory leak detection |
| GB2571996B (en) * | 2018-03-16 | 2020-09-09 | Advanced Risc Mach Ltd | Branch target variant of branch-with-link instruction |
| US10824635B2 (en) | 2019-01-30 | 2020-11-03 | Bank Of America Corporation | System for dynamic intelligent code change implementation |
| US10853198B2 (en) | 2019-01-30 | 2020-12-01 | Bank Of America Corporation | System to restore a transformation state using blockchain technology |
| US10768907B2 (en) | 2019-01-30 | 2020-09-08 | Bank Of America Corporation | System for transformation prediction with code change analyzer and implementer |
| CN114428694A (zh) * | 2020-10-29 | 2022-05-03 | 华为技术有限公司 | 一种错误检测方法及相关装置 |
| CN113342565A (zh) * | 2021-06-25 | 2021-09-03 | 珠海菲森电力科技有限公司 | 一种防止内存泄漏的方法及系统 |
| US20230305867A1 (en) * | 2022-03-23 | 2023-09-28 | Red Hat, Inc. | Layered operating system |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5179702A (en) * | 1989-12-29 | 1993-01-12 | Supercomputer Systems Limited Partnership | System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling |
| US5193180A (en) * | 1991-06-21 | 1993-03-09 | Pure Software Inc. | System for modifying relocatable object code files to monitor accesses to dynamically allocated memory |
| US5581697A (en) * | 1994-01-28 | 1996-12-03 | Sun Microsystems, Inc. | Method and apparatus for run-time error checking using dynamic patching |
| US5675803A (en) * | 1994-01-28 | 1997-10-07 | Sun Microsystems, Inc. | Method and apparatus for a fast debugger fix and continue operation |
| US5600790A (en) * | 1995-02-10 | 1997-02-04 | Research In Motion Limited | Method and system for loading and confirming correct operation of an application program in a target system |
| US5727178A (en) * | 1995-08-23 | 1998-03-10 | Microsoft Corporation | System and method for reducing stack physical memory requirements in a multitasking operating system |
-
1996
- 1996-02-05 EP EP96300759A patent/EP0729097A1/en not_active Withdrawn
- 1996-02-07 JP JP8044104A patent/JPH0922370A/ja active Pending
-
1997
- 1997-11-25 US US08/976,448 patent/US5953530A/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000122882A (ja) * | 1998-10-20 | 2000-04-28 | Matsushita Electric Ind Co Ltd | マルチスレッドプロセッサおよびデバッグ装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP0729097A1 (en) | 1996-08-28 |
| US5953530A (en) | 1999-09-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH0922370A (ja) | マルチスレッド・ターゲット・プログラムのメモリ・アクセス・チェック方法及び装置 | |
| US6480818B1 (en) | Debugging techniques in a multithreaded environment | |
| US6854108B1 (en) | Method and apparatus for deterministic replay of java multithreaded programs on multiprocessors | |
| Weiser et al. | The portable common runtime approach to interoperability | |
| US7117330B1 (en) | Synchronization techniques in a multithreaded environment | |
| US5454086A (en) | Dynamic program analyzer facility | |
| Anderson et al. | Scheduler activations: Effective kernel support for the user-level management of parallelism | |
| Jula et al. | Deadlock Immunity: Enabling Systems to Defend Against Deadlocks. | |
| Nethercote et al. | Valgrind: A program supervision framework | |
| Massalin et al. | A lock-free multiprocessor OS kernel | |
| US9268666B2 (en) | System and method for debugging of computer programs | |
| US5583988A (en) | Method and apparatus for providing runtime checking features in a compiled programming development environment | |
| US6886081B2 (en) | Method and tool for determining ownership of a multiple owner lock in multithreading environments | |
| US5949972A (en) | System for memory error checking in an executable | |
| US20020046230A1 (en) | Method for scheduling thread execution on a limited number of operating system threads | |
| EP1369787A2 (en) | Processor device and information processing device, compiling device, and compiling method using said processor device | |
| EP2600252B1 (en) | System and method for debugging of computer programs | |
| Schulz et al. | A thread-aware debugger with an open interface | |
| Baur | Instrumenting Java bytecode to replay execution traces of multithreaded programs | |
| Narten | A Road Map Through Nachos | |
| Frei et al. | A Dynamic AOPEngine for. NET | |
| Holmes et al. | A designer's perspective of the hawk multiprocessor operating system kernel | |
| Schmidt et al. | Thread-Specific Storage for C/C+ | |
| Chen et al. | Kernel instrumentation tools and techniques | |
| Wong | Mac OS X on L4 |