JPH103403A - 計算機システムおよびデバッグ方法 - Google Patents

Abstract

(57)【要約】 【課題】ソフトウェアの障害を調査するための情報を効
率的に収集することのできる計算機システム。 【解決手段】プログラムの実行過程を追跡するためのト
レース情報をトレース領域２３に収集するトレース機能
を有し、中断した処理を再開始するために、チェックポ
イントイメージを適宜チェックポイント領域２２に採取
する計算機システムにおいて、計算機システムの通常稼
働時には、トレース機能によるトレース領域２３へのト
レース情報の収集を行なわず、障害によりチェックポイ
ント領域２２に採取したチェックポイントイメージを復
元して再開始するときに、トレース機能によるトレース
領域２３へのトレース情報の収集を開始する。これによ
り、通常稼働時にはトレース情報採取のためのオーバー
ヘッドを発生させずに、障害解析に必要なトレース情報
を採取することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、たとえばチェッ
クポイントとロールバックとを用いて故障回復を可能と
する計算機システムおよびデバッグ方法に係り、特にソ
フトウェアの障害を調査するための情報を効率的に収集
することのできる計算機システムおよびデバッグ方法に
関する。

【０００２】

【従来の技術】近年、様々な業種で処理の電子化が図ら
れており、これらの電子化を担う計算機システムでは、
より高度の信頼性が常に要求されている。そして、この
ような信頼性の向上を実現する計算機システムとして、
チェックポイント／リカバリ方式の計算機システムが存
在する。

【０００３】このチェックポイント／リカバリ方式の計
算機システムは、中断した処理を再開始するためのチェ
ックポイントを適宜採取しながら処理を進行させてい
き、障害などによって処理が中断されたときに、その採
取しておいたチェックポイントから処理を再開始するこ
とによってリカバリを行なうといった計算機システムで
ある。この計算機システムによれば、実行途中であった
トランザクションを失なうことなく、かつシステム全体
の整合性を損なうことなくリカバリを行なうことができ
るため、システムダウンの頻度を大幅に低下させること
が可能となる。

【０００４】しかしながら、このチェックポイント／リ
カバリ方式の計算機システムにおいては、障害などによ
って処理が中断されたときに、その時点で収集可能な情
報のみを採取して、直前に採取したチェックポイントか
ら即座に再開始を行なってしまうため、その障害の要因
がソフトウェアのバグによるものであった場合には、情
報不足によって十分な調査が行なえない、すなわちソフ
トウェアのデバッグについての考慮がされていないとい
った問題があった。

【０００５】

【発明が解決しようとする課題】このように、従来のチ
ェックポイント／リカバリ方式の計算機システムにおい
ては、ソフトウェアのデバッグについての考慮がされて
いないために、たとえばソフトウェアの動作を調査する
ために必要な情報をほとんど収集することができないと
いった問題があった。

【０００６】この発明はこのような実情に鑑みてなされ
たものであり、チェックポイント／リカバリ方式の計算
機システムにおいて、ソフトウェアの障害を調査するた
めの情報を効率的に収集することのできる計算機システ
ムおよびデバッグ方法を提供することを目的とする。

【０００７】

【発明を解決するための手段】この発明は、中断した処
理を再開始するためのチェックポイントを適宜採取する
計算機システムであって、プログラムの実行過程を追跡
するためのトレース情報を収集するトレース機能を有し
てなる計算機システムにおいて、前記トレース機能の有
効／無効を設定する設定手段と、前記計算機システムの
通常稼働時には、前記設定手段により前記トレース機能
を無効に設定しておき、前記チェックポイントから再開
始するときに、前記設定手段により前記トレース機能を
有効に設定するシステム制御手段とを具備してなること
を特徴とする。

【０００８】この発明においては、システム制御手段
が、通常稼働時にはトレース機能を無効（使用しない）
としておき、障害によりチェックポイントからの再開始
を行なうときに、トレース機能を有効（使用する）とす
るように計算機システムを制御する。したがって、通常
稼働時にはトレース情報採取のためのオーバーヘッドを
発生させることがなく、一方、障害発生時には障害解析
に必要なトレース情報が採取されることになる。

【０００９】また、この発明は、会話的に実行を制御し
てプログラムの動作調査を支援するデバッガと、前記チ
ェックポイントから再開始した後、その再開始を誘発し
た事象の再発を検出する検出手段とをさらに具備し、前
記システム制御手段は、前記検出手段が前記再開始を誘
発した事象の再発を検出したときに、前記デバッガを起
動する手段を具備してなることを特徴とする。

【００１０】この発明においては、チェックポイントか
らの再開始を行なった後（トレース機能オン）、その再
開始を誘発した事象が再度発生したときに、その旨を検
出するとともに、その検出した時点でデバッガを起動す
る。したがって、ユーザはチェックポイントから障害再
発時点までのトレース情報を得ることができ、さらにそ
の時点で自動的に起動されるデバッガを利用して、障害
を引き起こしたプログラムの障害発生時点での状態など
を知ることができるため、障害調査の効率は飛躍的に向
上する。

【００１１】また、この発明は、前記再開始を誘発した
事象に関する情報を少なくとも２組以上記憶する記憶領
域を備え、前記検出手段は、前記記憶領域に記憶された
前記再開始を誘発した事象すべてを検出対象とすること
を特徴とする。

【００１２】チェックポイントからの再開始を行なった
場合、前回とまったく同じ手順で計算機システムが稼働
するとは限らない。したがって、再開始を誘発した事象
とは異なる事象の障害が発生することは十分に考えられ
ることである。このようなことを考慮して、この発明に
おいては、再開始を誘発した事象に関する情報を少なく
とも２組以上記憶する記憶領域を備えておく。そして、
チェックポイントからの再開始を行なった後、再開始を
誘発したいずれかの事象が再度発生したときに、その旨
を検出するとともに、その検出した時点でデバッガを起
動する。すなわち、複数の障害を調査対象とすることに
よって、広範囲のサポートが保証されることになる。

【００１３】この再開始を誘発した事象の再発の検出
は、たとえばコンテクスト情報に含まれるプログラムカ
ウンタ値などによって行なうことが可能である。すなわ
ち、障害発生時のプロセッサの状態が一致したときに、
再開始を誘発した事象が再発したと判定する。また、た
とえばアサート文（たとえば障害検出判定条件）などに
よって行なうことも可能である。これによれば、障害時
に実行中であったプログラムが異なっていたり、プログ
ラム内でのアドレスが異なっていた場合であっても、障
害要因の一致によって再開始を誘発した事象が再発され
たと判定する。なお、これらの設定は、計算機システム
の運用によって決定・選択されるものである。

【００１４】また、たとえばチェックポイントから再開
始した後、この再開始を誘発した事象が再発されずに次
のチェックポイントを採取すべき状況になったとき、そ
のチェックポイントを採取して処理を継続する、または
直前のチェックポイントからの再開始を繰り返すなどを
選択的に行なうことも有効である。障害調査の重要性と
処理継続の重要性とを比較して、処理継続が優先される
場合には、そのまま次のチェックポイントを採取して処
理を継続することが望ましく、一方、障害調査が優先さ
れる場合には、その障害が再現されるまで、再開始を繰
り返すことが望ましい。なお、記憶領域などの資源の有
効利用を考慮すれば、この再開始を繰り返す際に、トレ
ース機能により収集したトレース情報を破棄するといっ
たことを行なうことが好ましい。

【００１５】また、この発明は、前記計算機システム
は、前記チェックポイントを所定の間隔で定期的に採取
し、前記システム制御手段は、前記チェックポイントか
ら再開始したときに、次のチェックポイントの採取を遅
延させる手段を具備してなることを特徴とする。

【００１６】チェックポイントを所定の間隔で定期的に
採取する計算機システムの場合、チェックポイントの採
取間隔を意図的に広くするといったことが可能である。
そして、チェックポイントから再開始する際、次のチェ
ックポイントの採取を遅延させれば、再開始を誘発した
事象を再現させる頻度を向上させることができる。この
チェックポイント採取間隔の変更は、再開始を最初に行
なうときに行なってもよいし、たとえば予め設定された
回数を越えて再開始を繰り返すときに行なってもよい。
また、この繰り返した回数と遅延間隔とを多段階で設定
しておくことも有効である。

【００１７】また、この発明は、前記計算機システム
は、前記チェックポイントを少なくとも２世代以上採取
し、前記システム制御手段は、直前に採取されたチェッ
クポイント以前のチェックポイントから再開始する手段
を具備してなることを特徴とする。

【００１８】チェックポイントが採取された直後に障害
が発生した場合、このチェックポイントからのトレース
情報だけでは十分な調査が行なえないことが予想され
る。また、チェックポイントが採取される前の事象に起
因して、チェックポイント採取後に障害が発生すること
も十分に考えられる。そこで、この発明では、少なくと
も２世代以上のチェックポイントを採取しておき、障害
発生時の再開始を直前に採取されたチェックポイント以
前のチェックポイントから行なう。これにより、前述し
たような状況で発生した障害に関する情報を収集できる
可能性を高くすることが可能となる。

【００１９】また、この発明は、中断した処理を再開始
するためのチェックポイントを適宜採取する計算機シス
テムにおいて、予め指定されたステップで前記チェック
ポイントの採取を待機させるプログラム制御手段を具備
してなることを特徴とする。

【００２０】たとえば、調査対象としたいプログラムが
存在し（複数でも構わない）、かつトレース情報を採取
したいステップが明らかになっているような場合には、
そのステップの直前で、チェックポイントの採取を待機
させる。したがって、調査対象としているプログラムが
障害を発生させると、再開始されるチェックポイント
は、そのプログラム内のトレース情報を採取したいステ
ップの直前となり、ユーザは、所望する箇所のトレース
情報のみを採取することができるため、障害調査の効率
を向上させることが可能となる。

【００２１】また、この発明は、中断した処理を再開始
するためのチェックポイントを適宜採取する計算機シス
テムにおいて、デバッグに必要な情報を収集するための
ステップを含むデバッグ用の関数とこれらのステップを
含まない通常稼働用の関数とをすべての関数それぞれに
対応して格納するライブラリと、前記計算機システムの
通常稼働時には、前記通常稼働用の関数を呼び出し対象
としておき、前記チェックポイントから再開始するとき
に、前記デバッグ用の関数を呼び出し対象に切り替える
システム制御手段とを具備してなることを特徴とする。

【００２２】この発明においては、たとえばプリンタに
変数の値を出力するなどといったデバッグに必要な情報
を収集するためのステップを含むデバッグ用の関数と、
このようなステップを含まない通常稼働用の関数とを用
意しておき、通常稼働時と再開始時とで呼び出し対象と
する関数を切り替える。これにより、通常稼働時にはト
レース情報採取のためのオーバーヘッドを発生させるこ
とがなく、かつ一方で、障害解析に必要なトレース情報
は採取されることになる。なお、コンテクスト情報に含
まれるプログラムカウンタ値などによって、障害を発生
させた関数を検出し、この検出した関数のみをデバッグ
用の関数に切り替えれば、必要なトレース情報のみを採
取することができるため、障害調査の効率を向上させる
ことが可能となる。

【００２３】

【発明の実施の形態】以下、図面を参照してこの発明の
実施の形態を説明する。図１は本実施形態に係る計算機
システムのシステム構成を示す図である。図１に示した
ように本実施形態の計算機システムは、ＣＰＵを内蔵す
るプロセッサ１１、主メモリ２、および各種外部記憶装
置３を備えて構成される。

【００２４】プロセッサ１は、計算機システム全体の制
御を司り、主メモリ２に格納されたオペレーティングシ
ステムやユーティリティプログラムを含むアプリケーシ
ョンプログラムを実行制御する。

【００２５】主メモリ２は、オペレーティングシステム
やユーティリティプログラムを含むアプリケーションプ
ログラムと、これらが使用するデータとを格納する。こ
の主メモリ２は、オペレーティングシステムが通常時に
使用するＯＳ使用領域２１と、入出力処理やプロセッサ
１の処理状態などを含むチェックポイントイメージを格
納するチェックポイント領域２２と、ＯＳのトレース情
報を格納するトレース領域２３と、障害発生時点で採取
可能な情報を格納する障害情報領域２４とに分割されて
いる。そして、この主メモリ２は、ＯＳ使用領域２１の
みが、故障発生時にリカバリの対象領域とされており、
チェックポイント領域２２、トレース領域２３および障
害情報領域２４は、リカバリの対象領域とならないよう
に構成されている。

【００２６】そして、外部記憶装置３は、二次記憶装置
として用いられ、主メモリ２との間でデータ転送が行な
われる。また、この外部記憶装置３には、計算機システ
ムが異常を検出したときのシステムダンプ情報が格納さ
れる。

【００２７】このような構成をもつ本実施形態の計算機
システムでは、障害の発生などで中断した処理を再開始
するためのチェックポイントを定期的に採取しており、
この採取したチェックポイントイメージ（コンテクスト
情報、メモリ更新情報など）を、チェックポイント領域
２２に格納している。

【００２８】ここで、この計算機システムに障害が発生
したときの動作を説明する。図２には、この計算機シス
テムに障害が発生したときの動作原理が示されている。
この計算機システムにおいて、システム異常が検出され
た場合（図２の（１））、計算機システムは、リカバリ
処理を開始する（図２の（２））。リカバリ処理では、
まず検出した故障がソフトウェア障害によるものかどう
かを調査し、ハードウェアに起因する故障であると判定
された場合には、通常のシステムクラッシュ処理を実行
する。一方、ソフトウェアバグによる障害であると確認
された場合には、異常を検出した直前に採取したチェッ
クポイントイメージをチェックポイント領域２２から取
り出して、計算機システムの状態を異常を検出した直前
に採取したチェックポイントまで戻した後、オペレーテ
ィングシステムのトレース機能を有効にし、計算機シス
テムの処理を異常を検出した直前に採取したチェックポ
イントから再開始する（図２の（３））。

【００２９】ここで、トレース機能について説明する。
通常、オペレーティングシステムの有するトレース機能
は、オペレーティングシステム内に予め組み込まれるも
のであり、この機能を用いてトレース情報を採取する場
合には、計算機システムを起動するときに設定する、ま
たはオペレーティングシステムのコマンドによって設定
する、などといった事前の設定を必要とする。トレース
情報として採取される情報としては、カーネル内の動作
状況、プロセスの実行状況、入出力割り込み、およびイ
ベント発生情報などが挙げられ、オペレーティングシス
テムだけではなく、オペレーティングシステム上で動作
するアプリケーションプログラムについてもトレース情
報が採取される。本実施形態の特徴は、このトレース機
能の有効（使用する）／無効（使用しない）の設定をシ
ステム起動時などに行なうのではなく、リカバリ処理内
で行なう（たとえば前述したオペレーティングシステム
コマンドの発行など）ことにある。

【００３０】これにより、通常稼働時にはトレース情報
採取のためのオーバーヘッドを発生させることがなく、
一方で、障害発生時には障害解析に必要なトレース情報
が採取されることになる。すなわち、ソフトウェア障害
により直前のチェックポイントから再開始した計算機シ
ステムでは、オペレーティングシステムのトレース情報
をトレース領域２３に格納しながら異常を検出するまで
処理を続けるので、再度異常を検出した場合には（図２
の（４））、トレース情報がトレース領域２３に、異常
検出時のシステムダンプ情報が外部記憶装置３にそれぞ
れ採取されることになり、ソフトウェアバグによる障害
の解析に必要な情報を容易に採取することが可能とな
る。

【００３１】また、リカバリ処理において、システム異
常時の障害情報を、オペレーティングシステムが通常使
用しない主メモリ２の障害情報領域２４に保存してお
き、計算機システムを再開始した後、再度システム異常
が発生した場合には、この保存しておいた障害情報と、
再発生したシステム異常時の障害情報とを比較する。こ
の比較は、たとえば、再開始で検出された障害が０番地
に対する不正アクセスによる例外要因であるならば、前
回採取した障害情報から例外要因、不正アクセスされた
番値、プログラムカウンタの値などを抽出したのち、今
回検出した障害情報と比較するなどによって実施する。
そして、その抽出した情報と今回の情報とが等しい場合
には、前回と同一の障害が発生したとみなして計算機シ
ステムを停止し、デバッガを起動する。

【００３２】このデバッガは、会話的に実行を制御して
プログラムの動作調査を支援するものであり、システム
の開発や、保守・整備などのためにほとんどの計算機シ
ステムに備えられるものである。そして、このデバッガ
を障害の再発時に自動的に起動すれば、異常が発生した
直後のシステム状態を調査することができ、チェックポ
イントから障害再発時点までのトレース情報と併せて、
ソフトウェアのバグによる障害の解析に必要な情報を容
易に採取することが可能となる。

【００３３】なお、同一の障害が発生したかどうかの判
定手段としては、前述したプロセッサ１の情報以外に、
異常を検出するために組み込まれているアサート文（ア
サート文のあるアドレスや、システムが正常であるか否
かを判定するアサートの条件など）によって判定するこ
とも有効である。たとえば、ロックの獲得ミスや、同一
メモリ領域に対する重複した解放要求などを原因とした
障害の場合、障害時に実行中であったプログラムが異な
っていたり、プログラム内でのアドレスが異なっていた
場合であっても、障害要因の一致によって同一の障害と
判定し、その時点でデバッガを起動することによって各
種情報を採取すれば、障害に対する早期の対応が可能と
なる。

【００３４】また、障害情報領域２４を複数の障害情報
が格納できるように構成しておくことも有効である。す
なわち、再開始後に検出した障害が前回の障害と異なる
場合には、障害情報領域２４にさらにこのときの障害情
報を格納した後、システムの再開始を行なう。これによ
り、ソフトウェアに潜んでいるバグに関する情報を採取
する機会を増加させることができる。

【００３５】次に、図３を参照して本実施形態のリカバ
リ処理の動作手順を説明する。システム異常が検出され
ると、計算機システムは、検出した故障がソフトウェア
障害によるものかどうかを調査し（ステップＡ１）、ハ
ードウェアに起因する故障であると判定された場合には
（ステップＡ１のＮ）、通常のシステムクラッシュ処理
を実行する（ステップＡ２）。一方、ソフトウェアバグ
による障害であると確認された場合には（ステップＡ１
のＹ）、この障害が最初のものであるかどうか（トレー
ス情報が採取されていない状態での故障）を判定する
（ステップＡ３）。ここで、最初の障害と判定された場
合（ステップＡ３のＹ）、計算機システムは、この障害
に関する情報を障害情報領域２４に保存し（ステップＡ
４）、異常を検出した直前に採取したチェックポイント
イメージをチェックポイント領域２２から取り出して計
算機システムの状態を異常を検出した直前に採取したチ
ェックポイントまで戻した後（ステップＡ５）、オペレ
ーティングシステムのトレース機能を有効にし（ステッ
プＡ６）、計算機システムの処理を異常を検出した直前
に採取したチェックポイントから再開始する。

【００３６】一方、最初の障害ではないと判定された場
合には（ステップＡ３のＮ）、この障害が前回（直前か
どうかは問わない）の障害と同じものであるかどうかを
判定し（ステップＡ７）、同じものであると判定した場
合には（ステップＡ７のＹ）、デバッガを起動して障害
調査に必要な情報を採取する（ステップＡ８）。そし
て、このようにして収集した情報（トレース情報やシス
テムダンプ情報など）を外部記憶装置３に保存した後
（ステップＡ９）、ステップＡ５と同様に、異常を検出
した直前に採取したチェックポイントイメージをチェッ
クポイント領域２２から取り出して計算機システムの状
態を異常を検出した直前に採取したチェックポイントま
で戻した後（図示せず）、計算機システムの処理を異常
を検出した直前に採取したチェックポイントから再開始
する。

【００３７】これにより、通常稼働時にトレース情報採
取のためのオーバーヘッドを発生させずに、障害解析に
必要な情報を効率良く収集することが可能となる。な
お、ソフトウェアのバグによって障害が発生し、この障
害を計算機システムが検出した後、その異常を検出した
直前に採取したチェックポイントから処理を再開始した
としても、各プロセスの動作状況や入出力装置からの割
り込み発生のタイミングなどにより、その障害が再発す
るとは限らない。したがって、このことを考慮して、そ
の障害が再発せずに次のチェックポイントを採取すべき
状況になったときに、そのチェックポイントを採取して
処理を継続する、または直前のチェックポイントからの
再開始を繰り返すなどを選択的に行なうことも有効であ
る。すなわち、障害調査の重要性と処理継続の重要性と
を比較して、処理継続が優先される場合には、そのまま
次のチェックポイントを採取して処理を継続することが
望ましく、一方、障害調査が優先される場合には、その
障害が再現されるまで、再開始を繰り返すことが望まし
い。この再開始を繰り返す際の動作原理を図４を参照し
て説明する。

【００３８】システムの障害が検出された場合（図４の
（１））、計算機システムは、リカバリ処理を実施し
（図４の（２））、トレース機能を有効にした後にチェ
ックポイントからの再開始を実施する（図４の
（３））。その後、その障害が再発せずに次のチェック
ポイントを採取すべき状況になったとき（図４の
（４））、計算機システムは、再度リカバリ処理を繰り
返して計算機システムの状態を異常を検出した直前に採
取したチェックポイントに復元する（図４の（５））。
このとき、計算機システムは、記憶領域などの資源の有
効利用を考慮して、トレース機能により収集したトレー
ス情報を破棄する。そして、計算機システムは、再度復
元された異常を検出した直前に採取したチェックポイン
トから再開始を実施する（図４の（６））。

【００３９】これにより、ある種のタイミングによって
発生するソフトウェア障害についても非常に高い確率で
障害を再現させることが可能となり、従来であればあき
らめざるを得なかった、障害解析に必要な情報の採取が
可能になる。

【００４０】また、このようにチェックポイントからの
再開始を繰り返しても、障害が再現されない場合があ
る。たとえば、次のチェックポイントを採取する直前で
障害を検出した場合などであり、この場合には、オペレ
ーティングシステムのトレース機能を有効とした結果、
トレース情報を採取するための処理が追加されることに
より、次のチェックポイントを採取するまでに、その障
害を発生させた処理を実行できないことがある。

【００４１】これを回避するために、障害を検出した直
前に採取したチェックポイントから再開始するときに、
リカバリ処理内において次のチェックポイントを採取す
る間隔を延長する。これにより、前述したような状況で
あっても、次のチェックポイントを採取するまでに障害
を発生させた処理を実行させることが可能となり、障害
解析に必要な情報を採取することができることになる。
また、このチェックポイント採取間隔の延長を、最初の
再開始時に行なうのではなく、予め設定された回数を越
えて再開始を繰り返すときに行なうことも有効であり、
さらにこの回数と延長間隔とを多段階に設定可能とする
ことが好ましい。これにより、より柔軟な保守・整備が
可能となる。

【００４２】また、チェックポイントを採取した直後に
障害を検出した場合ような場合には、ソフトウェアのバ
グを解析するのに必要かつ十分な情報を得られない場合
がある。すなわち、このような場合に、リカバリ処理を
行ない、オペレーティングシステムのトレース機能を有
効にしてシステムを再開始しても、トレース情報として
採取される情報はごくわずかになってしまい、ソフトウ
ェアのバグによる障害を調査分析するだけの情報を得ら
れない。また、直前のチェックポイント以前に発生した
事象に起因して障害が発生した場合も、障害の原因とな
った事象を調査分析するための情報を得ることはできな
い。

【００４３】これを回避するために、チェックポイント
を採取する際、チェックポイント領域２２に複数のチェ
ックポイントイメージをいつ採取したか判定できるよう
に世代管理をして保存しておき、ソフトウェアのバグに
よる障害による異常を検出したときには、リカバリ処理
で、障害を検出した直前に採取したチェックポイントよ
り前のチェックポイントイメージで計算機システムの状
態を復元し、かつオペレーティングシステムのトレース
機能を有効にして再開始を実施する。この直前のチェッ
クポイントよりも前のチェックポイントから再開始を実
施する際の動作原理を図５を参照して説明する。

【００４４】計算機システムは、複数のチェックポイン
トイメージを世代管理してチェックポイント領域２２に
保存する（図５の（１），（２））。そして、システム
の障害が検出された場合に（図５の（３））、計算機シ
ステムは、リカバリ処理において直前のチェックポイン
トより前のチェックポイント（ここでは１つ前のチェッ
クポイント）を復元し（図５の（４））、トレース機能
を有効にした後にチェックポイントからの再開始を実施
する（図５の（５））。これにより、障害が再現された
際に、その障害を調査分析するのに必要かつ十分な情報
を得ることが可能となる。

【００４５】以上のように、複数の要因によるソフトウ
ェア障害で発生するようなシステム障害であっても、そ
の調査分析に必要かつ十分な情報を容易に得ることがで
きるため、障害対処の時間を大幅に短縮することが可能
となる。

【００４６】次に、通常のデータ処理の最中に、障害発
生に備えて定期的にチェックポイントを採取する機能を
備えたチェックポイント／リカバリ方式の計算機システ
ムにおけるプログラムのデバッグについて考える。

【００４７】たとえば、定期的にチェックポイントを採
取するチェックポイント機能は、チェックポイントを採
取した時点ですべてのプログラムに対して特定のイベン
トを通知するものとし、また、プログラム管理システム
は、プログラム側の要求に応じて、このイベントが通知
されるまで、そのプログラムの処理を一時的に待機させ
ることのできる機能を有しているものとする。

【００４８】このような計算機システムにおいて、プロ
グラムのデバッグを行なう場合、図６に示したように、
プログラム中のデバッグ対象とする部分（図６（ａ）の
４２）の直前に、チェックポイントの採取を示す通知の
受信を待機するステップ（図６（ａ）の４１）を設けて
おく。なお、この設定は、複数のプログラムについて行
なう（複数のプログラムをデバッグ対象とする）ことが
でき、また、一つのプログラム中に、デバッグ対象とす
る部分を複数設定しても構わない。その結果、プログラ
ム中のデバッグ対象部分４２の実行前の時点（４１）で
常にチェックポイントが採取されることになり、たとえ
ば障害発生（図６（ｂ）の４３）によってリカバリ処理
が行なわれた場合には、デバッグ対象部分４２の実行前
の時点（４１）から再開始されるため（図６（ｂ）の４
４）、デバッグ対象部分４２の調査分析を迅速に行なう
ことが可能となる。

【００４９】また、プログラムをデバッグする上で、関
係する複数の関数についてより詳細な情報を採取したい
場合がある。このような場合のデバッグを図７を参照し
て説明する。この場合、図７（ａ）に示したように、デ
バッグ対象になると思われる関数（ｆｕｎｃ（））（５
１）に対応させて、予め各種情報を採取するためのルー
チン（５２）を含んだデバッグ用の関数（Ａｌｔ＿ｆｕ
ｎｃ（））を用意しておき、このデバッグ対象の関数と
デバッグ用の関数のアドレスを、主メモリ２のチェック
ポイント領域２２に設けたプログラムデバッグ用テーブ
ル（図７（ｂ））に登録しておく。

【００５０】図７（ｂ）に示した例では、プログラムデ
バッグ用テーブルに、オペレーティングシステムをデバ
ッグするための情報として、割り込み処理（デバッグ対
象の関数：０ｘ００００１００００、デバッグ用の関
数：０ｘ０００２００００）と、スケジューラの関数
（デバッグ対象の関数：０ｘ００１３０１００、デバッ
グ用の関数：０ｘ００１８０２５０）とが格納されてい
る。

【００５１】この状態でプログラムを実行し、障害が発
生した場合には、計算機システムはリカバリ処理実行時
にプログラムデバッグ用テーブルを参照し、そこに登録
されているすべてのデバッグ対象の関数をデバッグ用の
関数に切り替える（図７（ｃ））。たとえば、割り込み
処理の関数の場合、０ｘ００００１０００にデバッグ用
の関数０ｘ０００２００００にジャンプする命令（５
３）を設定するなどである。そして、この後に計算機シ
ステムを再開始すると、システム再開始後にはデバッグ
対象となる関数が呼び出されることになり、デバッグに
必要な情報を採取することが可能になる。

【００５２】さらに、ある特定の関数についてデバッグ
を行なう場合を考える。ここでは、図８を参照して、関
数ａ（）をデバッグすることを考える。関数ａ（）につ
いてのより詳細な情報を収集するために、デバッグ用の
関数（ａｌｔ＿ａ（））を用意する（図８（ｂ））。そ
して、ユーザは、プログラム実行時にオペレーティング
システムに対してシステムコールを発行することによ
り、チェックポイント領域２２に設けたプログラムデバ
ッグ用のテーブル（（図８（ａ）））に、デバッグ対象
となる関数のアドレスと、そのサイズと、デバッグ用の
関数のアドレスとを登録する。

【００５３】この例では、関数ａ（）は、ＯＳ使用領域
２１の論理アドレス０ｘｆ０００００００で、サイズは
０ｘ１００、関数ａｌｔ＿ａ（）は、０ｘｆ０００１０
００にそれぞれ格納されているものとする。また、プロ
グラムデバッグ用テーブルには、関数ａ（）が登録され
る以前にオペレーティングシステムをデバッグするため
の情報（割り込み処理、スケジューラなど）が格納され
ているものとする。

【００５４】この状態で関数ａ（）を実行し、障害が発
生した場合に、計算機システムはリカバリ処理実行時に
障害情報領域２４に保存した障害情報から、その時点で
のプログラムカウンタの値を取り出した後、プログラム
デバッグ用テーブルのデバッグ対象の関数のアドレスと
サイズとを参照して、プログラムデバッグ用テーブルの
中に障害を発生させた関数が登録されていた場合には、
計算機システムの再開始時に、その関数をデバッグ用の
関数が実行されるように変更する。

【００５５】たとえば、障害を発生させたアドレスが０
ｘｆ０００００８０の場合、関数ａ（）で障害が発生し
たと判定することができるので、関数ａ（）のアドレス
０ｘｆ０００００００に、デバッグ用の関数ａｌｔ＿ａ
（）が存在する０ｘｆ０００１０００にジャンプする命
令を設定する（図８（ｃ））。そして、この設定後に計
算機システムの再開始を実施する。これにより、デバッ
グを必要とする関数に関する情報のみを収集することが
でき、デバッグ時間を短縮することが可能となる。

【００５６】

【発明の効果】以上詳述したように、この発明によれ
ば、通常稼働時にはトレース情報を採取せず、障害によ
りチェックポイントからの再開始を行なうときに、トレ
ース情報の採取を開始するために、通常稼働時にはトレ
ース情報採取のためのオーバーヘッドを発生させること
がなく、一方、障害発生時には障害解析に必要なトレー
ス情報のみが採取されることになる。

【００５７】また、障害が再現された場合に、会話的に
実行を制御してプログラムの動作調査を支援するデバッ
ガを自動的に起動するために、前述したチェックポイン
トから障害再発時点までのトレース情報とともに、障害
を引き起こしたプログラムの障害発生時点での状態など
を知ることができるため、障害調査の効率を飛躍的に向
上させることが可能となる。

【図面の簡単な説明】

【図１】この発明の実施形態に係る計算機システムのシ
ステム構成を示す図。

【図２】同実施形態の計算機システムに障害が発生した
ときの動作原理を示す図。

【図３】同実施形態のリカバリ処理の動作手順を説明す
るフローチャート。

【図４】同実施形態の再開始を繰り返す際の動作原理を
示す図。

【図５】同実施形態の直前のチェックポイントよりも前
のチェックポイントから再開始を実施する際の動作原理
を示す図。

【図６】同実施形態のプログラム中の任意の箇所でチェ
ックポイントの採取を待機させることにより障害情報を
収集する原理を示す図。

【図７】同実施形態のデバッグ用の関数を用いて障害情
報を収集する原理を示す図。

【図８】同実施形態の障害を発生させた関数を特定し、
その関数のみをデバッグ用の関数に切り替えることによ
って障害情報を収集する原理を示す図。

【符号の説明】

１…プロセッサ、２…主メモリ、３…外部記憶装置、２
１…ＯＳ使用領域、２２…チェックポイント領域、２３
…トレース領域、２４…障害情報領域。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 酒井 浩 東京都青梅市末広町２丁目９番地 株式会 社東芝青梅工場内

Claims (16)

【特許請求の範囲】
1. 【請求項１】 中断した処理を再開始するためのチェッ
   クポイントを適宜採取する計算機システムであって、プ
   ログラムの実行過程を追跡するためのトレース情報を収
   集するトレース機能を有してなる計算機システムにおい
   て、 前記トレース機能の有効／無効を設定する設定手段と、 前記計算機システムの通常稼働時には、前記設定手段に
   より前記トレース機能を無効に設定しておき、前記チェ
   ックポイントから再開始するときに、前記設定手段によ
   り前記トレース機能を有効に設定するシステム制御手段
   とを具備してなることを特徴とする計算機システム。
2. 【請求項２】 前記チェックポイントから再開始した
   後、その再開始を誘発した事象の再発を検出する検出手
   段とをさらに具備し、 前記システム制御手段は、前記検出手段が前記再開始を
   誘発した事象の再発を検出したときに、プログラムの実
   行を停止する手段を具備してなることを特徴とする請求
   項１記載の計算機システム。
3. 【請求項３】 会話的に実行を制御してプログラムの動
   作調査を支援するデバッガと、 前記チェックポイントから再開始した後、その再開始を
   誘発した事象の再発を検出する検出手段とをさらに具備
   し、 前記システム制御手段は、前記検出手段が前記再開始を
   誘発した事象の再発を検出したときに、前記デバッガを
   起動する手段を具備してなることを特徴とする請求項１
   記載の計算機システム。
4. 【請求項４】 前記再開始を誘発した事象に関する情報
   を少なくとも２組以上記憶する記憶領域を備え、 前記検出手段は、前記記憶領域に記憶された前記再開始
   を誘発した事象すべてを検出対象とすることを特徴とす
   る請求項２または３記載の計算機システム。
5. 【請求項５】 前記検出手段は、前記再開始を誘発した
   事象を特定するコンテクスト情報により前記再開始を誘
   発した事象の再発を検出することを特徴とする請求項
   ２、３または４記載の計算機システム。
6. 【請求項６】 前記検出手段は、前記再開始を誘発した
   事象を検出する検出判定条件の種別により前記再開始を
   誘発した事象の再発を検出することを特徴とする請求項
   ２、３または４記載の計算機システム。
7. 【請求項７】 前記システム制御手段は、前記チェック
   ポイントから再開始した後、前記検出手段が前記再開始
   を誘発した事象の再発を検出することなく次のチェック
   ポイントを採取すべき状況になったときに、そのチェッ
   クポイントを採取して処理を継続する手段を具備してな
   ることを特徴とする請求項２、３または４記載の計算機
   システム。
8. 【請求項８】 前記システム制御手段は、前記チェック
   ポイントから再開始した後、前記検出手段が前記再開始
   を誘発した事象の再発を検出することなく次のチェック
   ポイントを採取すべき状況になったときに、前記チェッ
   クポイントからの再開始を繰り返す手段を具備してなる
   ことを特徴とする請求項２、３または４記載の計算機シ
   ステム。
9. 【請求項９】 前記システム制御手段は、前記チェック
   ポイントからの再開始を繰り返す際、前記トレース機能
   により収集したトレース情報を破棄する手段を具備して
   なることを特徴とする請求項８記載の計算機システム。
10. 【請求項１０】 前記計算機システムは、前記チェック
    ポイントを所定の間隔で定期的に採取し、 前記システム制御手段は、前記チェックポイントから再
    開始したときに、次のチェックポイントの採取を遅延さ
    せる手段を具備してなることを特徴とする請求項８記載
    の計算機システム。
11. 【請求項１１】 前記計算機システムは、前記チェック
    ポイントを所定の間隔で定期的に採取し、 前記システム制御手段は、前記チェックポイントからの
    再開始を予め設定された回数を越えて繰り返すときに、
    次のチェックポイントの採取を遅延させる手段を具備し
    てなることを特徴とする請求項８記載の計算機システ
    ム。
12. 【請求項１２】 前記計算機システムは、前記チェック
    ポイントを少なくとも２世代以上採取し、 前記システム制御手段は、直前に採取されたチェックポ
    イント以前のチェックポイントから再開始する手段を具
    備してなることを特徴とする請求項１、２、３、４また
    は８記載の計算機システム。
13. 【請求項１３】 中断した処理を再開始するためのチェ
    ックポイントを適宜採取する計算機システムにおいて、 予め指定されたプログラム内の指定されたステップを実
    行する直前で前記チェックポイントの採取を待機させる
    プログラム制御手段を具備してなることを特徴とする計
    算機システム。
14. 【請求項１４】 中断した処理を再開始するためのチェ
    ックポイントを適宜採取する計算機システムにおいて、 デバッグに必要な情報を収集するためのステップを含む
    デバッグ用の関数とこれらのステップを含まない通常稼
    働用の関数とをすべての関数それぞれに対応して格納す
    るライブラリと、 前記計算機システムの通常稼働時には、前記通常稼働用
    の関数を呼び出し対象としておき、前記チェックポイン
    トから再開始するときに、前記デバッグ用の関数を呼び
    出し対象に切り替えるシステム制御手段とを具備してな
    ることを特徴とする計算機システム。
15. 【請求項１５】 前記チェックポイントからの再開始を
    誘発した関数を検出する検出手段をさらに具備し、 前記システム制御手段は、前記チェックポイントから再
    開始するときに、前記検出手段が検出した関数のみをデ
    バッグ用の関数を呼び出し対象に切り替えることを特徴
    とする請求項１３記載の計算機システム。
16. 【請求項１６】 中断した処理を再開始するためのチェ
    ックポイントを適宜採取する計算機システムであって、
    プログラムの実行過程を追跡するためのトレース情報を
    収集するトレース機能を有してなる計算機システムに適
    用されるデバッグ方法において、 前記計算機システムの通常稼働時には、前記トレース機
    能を無効に設定しておき、前記チェックポイントから再
    開始するときに、前記トレース機能を有効に設定するこ
    とを特徴とするデバッグ方法。