(57)【特許請求の範囲】
【請求項１】
システム内で異常が発生した場合に該システムの主記憶の内容を外部記憶装置へ書き出すコアダンプを行うコンピュータシステムにおいて、
前記コアダンプの要求の有無を表す要求データを保持するための、前記主記憶上の所定位置に設けられたフラグと、システムのハードウェアリセットによって保持内容が影響を受けない不揮発性媒体とを有する保持手段と、
前記異常の発生を示す事象を検出した時点で、前記異常の種類に応じて、前記コアダンプの要求を示す要求データを前記フラグ及び前記不揮発性媒体のいずれか一方に設定する設定手段と、
前記異常の発生に伴って起動されるシステムのリブート処理が完了してから、前記フラグに設定されている前記要求データの内容と前記不揮発性媒体に設定されている前記要求データの内容とを調べ、２つの該要求データのいずれか一方が前記コアダンプの要求を示していることを条件として前記コアダンプを行うコアダンプ手段と
を具備することを特徴とするコンピュータシステム。
【請求項２】
システム上を走行するプログラムでジャンプが発生したときのジャンプ先アドレスを記憶する記憶手段を有し、
前記設定手段は、前記ジャンプ先アドレスが前記プログラムの走行するはずのないアドレスであることを検出して、前記要求データを前記保持手段に設定することを特徴とする請求項１記載のコンピュータシステム。
【請求項３】
前記コアダンプ手段は、前記主記憶の内容を前記外部記憶装置上の固定領域に書き出すものであって、
該固定領域に書き出された前記主記憶の内容を前記外部記憶装置上の蓄積領域に蓄積してゆく蓄積手段をさらに有することを特徴とする請求項１又は２記載のコンピュータシステム。
【請求項４】
前記蓄積手段は、前記システム上を走行するアプリケーションプログラムに組み込まれ、前記主記憶の内容に圧縮処理を施してから前記外部記憶装置へ蓄積させてゆくことを特徴とする請求項３記載のコンピュータシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はコンピュータシステムに関し、特に、システム内でハングアップや異常が発生した場合に、主記憶装置の内容をハードディスク（以下、ＨＤＤという）等の大容量記憶装置へ書き出すコアダンプ処理に関するものである。
【０００２】
【従来の技術】
ワークステーション等のコンピュータシステムでは、システムがハングアップしたことを検出した場合や何らかの原因でアプリケーションが異常終了したような場合に、異常発生時点で主記憶装置に格納されているデータをＨＤＤといったより大容量の外部記憶装置へ転送することが行われている。こうした処理は一般にコアダンプ処理などと呼ばれている。こうしたコアダンプ処理はシステムを異常な状態から救済する目的で為されるほか、救済措置が奏功しなかったような場合は、原因究明のために行われる事後的な解析においてコアダンプされたデータが利用されることになる。
【０００３】
【発明が解決しようとする課題】
ところで、従来のコンピュータシステムでは異常が発生した時点ですぐにコアダンプ処理を行っている。すなわち、ＯＳ（オペレーティングシステム）が監視タイマ等でハングアップを検出するなど自ら異常を検出するか、あるいは、アプリケーションやハードウェアから異常の報告を受けると、ＯＳは異常処理の一環としてコアダンプ処理を行う。その後、ＯＳはコアダンプ処理を含む異常処理がすべて完了した時点でシステムをリブート（再起動）させている。
【０００４】
このように、従来のコンピュータシステムではＯＳが正常に動作していることを前提としてコアダンプ処理が行われている。しかしながら、異常が発生するような状況下ではシステム内で何が起きているか全く予測できないこともあり、場合によってはＯＳすら暴走するような状況に陥っていることも考えられる。特に、コンピュータシステムが組み込み機器などに用いられる場合は、過酷な環境下でシステムを動作させる必要が生じることも多々あり、ＯＳが正常に動作できない状況になってしまう蓋然性が高い。
【０００５】
以上の通り、従来のような方法を採用していたのではコアダンプ処理を常に確実に行える保証が得られず、コアダンプ処理の結果をもとに行われる救済措置や原因究明なども有効に行えないといった問題がある。
本発明は上記の点に鑑みてなされたものであり、その目的は、ＯＳすら暴走するような危機的な状況が発生した場合であっても、コアダンプ処理を確実に行ってコアダンプされた内容の信頼性を向上させられるコンピュータシステムを提供することにある。
【０００６】
【課題を解決するための手段】
以上の課題を解決するために、請求項１記載の発明は、システム内で異常が発生した場合に該システムの主記憶の内容を外部記憶装置へ書き出すコアダンプを行うコンピュータシステムにおいて、前記コアダンプの要求の有無を表す要求データを保持する保持手段と、前記異常の発生を示す事象を検出した時点で、前記コアダンプの要求を示す要求データを前記保持手段に設定する設定手段と、前記異常の発生に伴って起動されるシステムのリブート処理が完了してから前記要求データを調べ、該要求データが前記コアダンプの要求を示していることを条件として前記コアダンプを行うコアダンプ手段とを具備することを特徴としている。また、請求項２記載の発明は、請求項１記載の発明において、前記保持手段として、前記主記憶上の所定位置に設けられたフラグを有することを特徴としている。
また、請求項３記載の発明は、請求項１又は２記載の発明において、前記保持手段として、システムのハードウェアリセットによって保持内容が影響を受けない不揮発性媒体を有することを特徴としている。
【０００７】
また、請求項４記載の発明は、請求項１〜３の何れかの項記載の発明において、システム上を走行するプログラムでジャンプが発生したときのジャンプ先アドレスを記憶する記憶手段を有し、前記設定手段は、前記ジャンプ先アドレスが前記プログラムの走行するはずのないアドレスであることを検出して、前記要求データを前記保持手段に設定することを特徴としている。
また、請求項５記載の発明は、請求項１〜４の何れかの項記載の発明において、前記コアダンプ手段は、前記主記憶の内容を前記外部記憶装置上の固定領域に書き出すものであって、該固定領域に書き出された前記主記憶の内容を前記外部記憶装置上の蓄積領域に蓄積してゆく蓄積手段をさらに有することを特徴としている。
また、請求項６記載の発明は、請求項５記載の発明において、前記蓄積手段は、前記システム上を走行するアプリケーションプログラムに組み込まれ、前記主記憶の内容に圧縮処理を施してから前記外部記憶装置へ蓄積させてゆくことを特徴としている。
【０００８】
【発明の実施の形態】
以下、図面を参照して本発明の一実施形態について説明する。
まず最初に本発明についてその概要を説明する。従来の技術における問題点を考察して分かることは、コアダンプ機能を実現するプログラムはそれまでのシステム状態にかかわらず正常に動作する必要性があるほか、ＯＳを介在することなく動作可能なものでなければならない。そのためには、電源投入直後などのように未だＯＳも立ち上がっていない状態、すなわち、システムのブート時という初期化フェーズでコアダンプ処理を行う必要があることになる。
【０００９】
こうしたことから本発明は、従来のように異常発生時点ですぐコアダンプするのではなく、リブート時にコアダンプ処理を行うようにしている。ここで、コアダンプの要求はシステムの様々な状態において生じうる。そのため、本発明ではコアダンプ要求のための情報を様々な方法を用いてシステム上に残しておいた上でブートプログラムを起動し、当該プログラムによるリブート動作でシステムが正常に立ち上がってからコアダンププログラムを起動してコアダンプを行っている。
【００１０】
ちなみに、ブートプログラム側にコアダンプ機能を持たせるのではなく、システム上で走行するＯＳを含めた全てのプログラムにコアダンプ機能を持たせることも考えられる。しかし、システム上では、ユーザが通常走行させる一般的なアプリケーションプログラム，システムの初期設定及び状態確認を行うサービス用プログラム，生産時にシステムを検査するために使用する検査プログラムなど、様々なアプリケーションプログラムが走行する。これらプログラム全てにコアダンプ機能を重複させて組み込むことは、主記憶領域を無駄に消費するのみならず、アプリケーションを開発する上での負担も大きくなる。この点、コアダンプ機能を一つのコアダンププログラムとしてまとめれば主記憶を浪費することは無くなるが、アプリケーション全てにコアダンププログラムをリンクさせる必要があるため、やはりアプリケーション開発上の負担となる。したがってコアダンプ機能はブートプログラムに組み込むのが最適である。
【００１１】
さて、図１は本実施形態によるコンピュータシステムの構成を示すブロック図である。同図において、ＣＰＵ（中央処理装置）１０は、後述するＲＯＭ３０やＲＡＭ４０に格納された各種プログラムを実行することでシステム内の各部の動作を統括制御する。このＣＰＵ１０は一般的なマイクロプロセッサなどと同様にプログラムカウンタ，レジスタ類を備えているほか、スタック１１を具備している。ＣＰＵ１０はジャンプ命令を実行する度にジャンプ先のアドレスをスタック１１に設定する構成になっている。
【００１２】
ＨＤＤ２０はＲＡＭ４０（後述）上にロードされるシステムプログラム２１及びアプリケーションプログラム２２を予め格納している。これらのうち、システムプログラム２１はＯＳに相当するものである。また、アプリケーションプログラム２２は、アプリケーションとしての通常の動作を行うほか、コアダンプ処理が終了した後、採取されたコアダンプデータに圧縮処理を施してＨＤＤ２０上に蓄積してゆく機能を持っている。その際、ブートプログラム３１がコアダンププログラム３２を起動してコアダンプ処理を行った場合は、その旨をシステムプログラム２１に通知するようにしており、システムプログラム２１は当該通知に基づいてコアダンプが行われたかどうかをＲＡＭ４０上にレコードとして残しておく。アプリケーションプログラム２２はこのレコードの内容を参照することで、コアダンプが実施されたかどうを知ることができる。なお、かかる蓄積機能をブートプログラム３１でなくアプリケーションプログラム２２に組み込む理由は、圧縮処理というプログラムサイズの大きな処理が含まれているためであって、こうした機能をブートプログラム側に含ませて主記憶上に常駐させることが困難であることによる。したがって、圧縮処理を省くなどしてプログラムサイズを小さくすれば、ブートプログラム側に蓄積機能を持たせることも可能である。
【００１３】
このほか、ＨＤＤ２０には図２に示すような固定領域２３及び蓄積領域２４が設けられている。固定領域２３はコアダンプ処理によってＲＡＭ４０の内容の一部ないし全部が転送される領域であって、固定領域２３のＨＤＤ上における記憶位置は予め決められている。そのため、コアダンプ処理が行われると固定領域２３の内容はその都度書き換えられることになる。一方、蓄積領域２４はコアダンプの度に更新される固定領域２３の内容を順次蓄積してゆくための領域であって、アプリケーションプログラム２２の管轄下にあるファイルシステムで構成されるため、実際にはＨＤＤ２０上の任意の領域に設ければ良い。蓄積領域２４を設ける主たる理由は、異常な状態が何度も生じるような場合に採取したコアダンプをすべて保存しておき、これらを総合して原因解析を行うためである。
【００１４】
次に、ＲＯＭ（リードオンリーメモリ）３０は、システムをブートさせるためのブートプログラム３１とコアダンプ処理を行うコアダンププログラム３２を記憶している。なお、本実施形態においてはブートプログラム３１の先頭番地が０ｘ“ａ０００００００”番地（０ｘは１６進数を意味する標記）であるものとする。ここで、本実施形態によるコンピュータシステムでは０ｘ“ａ０００００００”番地と“０”番地が等価になっている。すなわち、論理的には命令アドレスとして３２ビットの値を指定することができるが、ＣＰＵ１０は命令アドレスの上位４ビットを常に“０”と見なす造りになっており、ｘ“ａ０００００００”番地は“０”番地と等しく扱われる。ただ、ブートプログラム３１へジャンプする際にジャンプ先として“０”番地を指定すると、プログラムにバグがあって“０”番地へジャンプした場合と区別することができなくなる。そこで本実施形態では、システムプログラム２１等が意図的にブートプログラム３１へジャンプする場合には、０ｘ“ａ０００００００”番地へジャンプするようにプログラムを作成している。
【００１５】
次に、ＲＡＭ（ランダムアクセスメモリ）４０は、ブートプログラム３１がＨＤＤ２０からロードするシステムプログラム２１及びアプリケーションプログラム２２を記憶するほか、これら各プログラムが使用する変数などを記憶する。これに加えて、ＲＡＭ４０は予め決められた所定位置に１バイトのフラグ４１（詳細については後述）を記憶している。
次に、ＰＵＩ（パネルユーザインタフェース）５０は、ユーザがフロントパネル５１を操作したときの操作内容を当該フロントパネル５１から受け取ってＣＰＵ１０へ伝達するインタフェース回路である。例えば、ＰＵＩ５０はフロントパネル５１上のリセットボタン（図示省略）が押されたことを知り、ＣＰＵ１０に対してＮＭＩ信号（Non-Maskable-Interrupt；マスク不可能な割り込み要求）を送出する。一般的なマイクロプロセッサと同様に、本実施形態ではＣＰＵに対する割り込みとしてマスク可能な割り込み（いわゆるＩＲＱ）とマスク不可能な割り込みがあるが、このＮＭＩ信号は最も優先度の高い割り込み要求である。また、ＰＵＩ５０はＮＭＩ信号をＣＰＵ１０へ送出してから一定時間が経過した後にシステム各部へリセット信号を送出する機能も持っている。
【００１６】
次に、ＲＴＣ（リアルタイムクロック）６０はＣＰＵ１０の制御下で動作するカレンダ用の集積回路であって、一般的なカレンダ機能を有するほか、汎用的に使用することの可能な汎用レジスタ６１を備えている。汎用レジスタ６１の内容はＣＰＵ１０が読み書き可能であり、また、この汎用レジスタ６１はバッテリバックアップされており、ハードウェアリセットを行ってもその内容が保持されるようになっている。なお、本実施形態では汎用レジスタ６１が４ビットで構成されているものとする。
次に、デバッグボード７０はシステムの開発段階でのみ接続されるデバッグ専用の回路である。
【００１７】
ところで、前述のようにコアダンプの要求は種々のシステム状態において生じうるが、本実施形態では以下に述べる事象を契機としてコアダンプ要求を行っている。
〔契機▲１▼ 〕プログラムによるコアダンプ付きリブート要求
システムプログラム２１やアプリケーションプログラム２２はプログラム走行中にソフトウェア的な異常を検出すると、システムプログラム２１内に予め用意されている関数（以下ではこれを SystemDown 関数とする）を呼び出す。この SystemDown 関数は、ＲＡＭ４０上のフラグ４１に所定値を書き込み、それによってコアダンプ要求を設定するようにしている。この所定値はどのような値でも良いが、本実施形態ではコアダンプ要求が存在しない場合に“０”が設定されるものとし、コアダンプ要求を設定する場合には“０”以外の任意の固定値として０ｘ“ＡＡ”を書き込むようにしている。また、 SystemDown 関数はフラグ４１へ所定値を格納した後に、ブートプログラム３１の先頭番地（すなわち、０ｘ“ａ０００００００”番地）へジャンプしてリブート処理を起動させる。
【００１８】
〔契機▲２▼〕フロントパネルからのリセット指示
システムの動作が異常であることをユーザが認識したような場合、ユーザはフロントパネル５１に設置されているリセットボタンを押下し、システムに対してハードウェアリセットの指示を行う。前述したように、リセットボタンの押下に伴ってＰＵＩ５０がＮＭＩ信号を発生させるため、このＮＭＩ信号が割り込み処理を担うシステムプログラム２１へのコアダンプ要求の契機となる。
【００１９】
〔契機▲３▼ 〕デバッグボードからの連続２回のリセット指示
先に説明したように、システムの開発段階では動作確認のためにデバッグボード７０が接続される。そこで、デバッグボード７０からコアダンプすべき状況（即ち、異常発生時に対応した状況）を意図的に再現可能とするために、デバッグボート７０からハードウェアリセットの指示が２回連続して行われた場合にこれをコアダンプ要求と見なす。なお、デバッグボード７０から２回連続してリセット指示があるかどうかはブートプログラム３１が判断する。すなわち、ブートプログラム３１はＲＡＭ４０上にカウンタを設けるようにしており、起動される度にカウンタの値を“１”増加させるほか、その後に行われるコアダンプ処理の直前で、カウンタの値が“２”になっていることを検出してコアダンプ要求を発生させる処理と、カウンタの値を“０”に初期化する処理を順次行うようにしている。なお、２回連続という条件を付したのは、コアダンプすべき状況にない場合でもデバッグボード７０がハードウェアリセットを出す場合があるためである。
【００２０】
〔契機▲４▼ 〕“０”番地へのジャンプ
アプリケーションやＯＳが正しくプログラミングされている限り、プログラムが“０”番地へジャンプすることは通常考えられない。しかし、アプリケーション等にバグが存在すると“０”番地にジャンプするような状況が生じうる。例えば、関数呼び出しを行う場合は呼び出される関数の先頭アドレスをポインタとして指定することになる。その場合、プログラムにバグがあってポインタに正しい値が設定されないと、デフォルトで設定される“０”がポインタに設定されてしまい、結果的に“０”番地（即ち、ブートプログラム３１の先頭アドレス）にジャンプしてしまう。こうしたことから、ブートプログラム３１は自身が“０”番地からのジャンプによって起動されたことを検出した場合は、これをコアダンプ要求としている。
【００２１】
次に、リブート後にコアダンプを行うための実現手段について説明する。
〔実現手段▲１▼〕
この実現手段では少なくともＯＳが正常に動いている状態を前提としており、前述した契機▲１▼に対応するものである。当該実現手段では、 SystemDown 関数が設定するフラグ４１を参照してその内容がｘ“ＡＡ”である場合にコアダンプ要求が存在していると判断する。上述したように、 SystemDown 関数は最終的に０ｘ“ａ０００００００”番地へ分岐してソフトウェア的にリブート処理を起動させている。換言すれば、前述の契機▲１▼ではハードウェアリセットを媒介としていないため、ＲＡＭ４０の記憶内容を信用することができる。したがって、ＲＡＭ４０上にフラグ４１を設け、異常発生時点でフラグ４１に値を設定し、リブート後に当該領域の内容に従ってコアダンプ処理の要否を判断しても問題はない。また、この実現手段では、フラグ４１の他にもエラー時における種々のデータを併せてＲＡＭ４０上に残すことができるという利点がある。
【００２２】
〔実現手段▲２▼〕
この実現手段は、ハングアップしている場合やＯＳが暴走している場合などのように、ハードウェアリセットを経由させてからリブートする必要があるときに用いられる実現手段である。つまり、この実現手段▲２▼は上述した契機▲２▼や契機▲３▼のためのものである（もっとも、契機▲１▼の場合などに用いることも可能である）。前述したように、ハードウェアリセットを行うと、リセット動作と命令実行動作が重なりあってＲＡＭ４０が予期せず書き換えられるなどの恐れがあり、その内容は信用できないものとなる。したがって、こうした場合にはＲＡＭ４０上のフラグ４１を用いている実現手段▲１▼が使用できない。
【００２３】
こうしたことから、本実現手段▲２▼ではＲＴＣ６０内に設けた汎用レジスタ６１を利用している。例えば、ユーザがフロントパネル５１のリセットボタンを押下する契機▲２▼の場合、システムプログラム２１はＮＭＩ信号による割り込み処理の過程で、汎用レジスタ６１に固定値として例えばｘ“ａ”を書き込んでおく。この後、ＮＭＩ信号から一定時間後にＰＵＩ５０がシステム各部にハードウェアリセットをかけるが、この場合にも汎用レジスタ６１の内容は不変である。したがって、ハードウェアリセット後に起動されるブートプログラム３１は、汎用レジスタ６１の内容が０ｘ“ａ”であればコアダンプ要求が存在するものと見なす。このほか、ブートプログラム３１はコアダンプ処理を行ったのちに、汎用レジスタ６１の内容を“０”に初期化して、次のコアダンプ要求が設定される場合に備える。
【００２４】
なお、実際の動作過程では、ブートプログラム３１はソフトウェア的に起動さされたのかハードウェア的に起動されたかに依らず、フラグ４１と汎用レジスタ６１の双方を常に調べるようにしている。つまり、ハードウェア的に起動されたのであれば汎用レジスタ６１にはコアダンプ要求が設定されており、また、ソフトウェア的に起動されたのであれば汎用レジスタ６１にコアダンプ要求は無くフラグ４１にだけコアダンプ要求が設定されている。また、不揮発性メモリなどのバッテリバックアップされた記憶手段を持つ構成とすることで、こうした記憶手段を汎用レジスタ６１の代わりに用いることができる。
【００２５】
〔実現手段▲３▼〕
この実現手段は、“０”番地へジャンプした結果としてブートプログラム３１が起動された場合に用いられるものであって、上述した契機▲４▼に対応する実現手段である。本実現手段▲３▼では、ブートプログラム３１がスタック１１に保持されたジャンプ先アドレスを参照し、その内容が“０”であれば“０”番地からのジャンプであると見なし、コアダンププログラム３２を起動してコアダンプ処理を行うようにしている。
【００２６】
次に、上記構成によるコンピュータシステムで行われるコアダンプ処理について説明する。なお、以下ではシステムプログラム２１及びアプリケーションプログラム２２が既にＲＡＭ４０上に読み込まれており、ＯＳやアプリケーションが走行して状況にあるものとする。
【００２７】
まず、上述した契機▲１▼が発生した場合について説明する。アプリケーションプログラム２２が実行中に何らかの異常を検出した場合、アプリケーションプログラム２２はシステムプログラム２１内の SystemDown 関数を呼び出す。これによって、システムプログラム２１はフラグ４１に０ｘ“ＡＡ”を書き込んでコアダンプ要求を設定したのち、ブートプログラム３１の先頭番地へジャンプする。ブートプログラム３１は、既存のブート処理を実行することにより、システムを正常に立ち上げるために最低限必要な初期化処理等を行う。次に、ブートプログラム３１は、フラグ４１および汎用レジスタ６１の内容をそれぞれ調べ、フラグ４１に０ｘ“ＡＡ”が設定されることを検出してコアダンプ要求を認識し、コアダンププログラム３２を起動してＲＡＭ４０の内容をＨＤＤ２０上の固定領域２３へ順次書き出してゆく。
【００２８】
このコアダンプ処理の後、ブートプログラム３１はフラグ４１及び汎用レジスタ６１をクリアするとともに、コアダンプを行ったことをシステムプログラム２１に通知するデータをＲＡＭ４０上に設定する。次に、ブートプログラム３１はシステムプログラム２１をＨＤＤ２０からＲＡＭ４０上にロードし、当該システムプログラム２１へ処理を委譲してＯＳを立ち上げる。この後、システムプログラム２１はコアダンプを行ったことを示すレコードを設定し、アプリケーションプログラム２２をＨＤＤ２０から読み出して起動させる。アプリケーションプログラム２２はアプリケーション本来の処理を行う前に、上記レコードからコアダンプが行われたことを知り、固定領域２３上に採取されたコアダンプデータを読み出してこれに圧縮処理を施したのち、蓄積領域２４上に新たにファイルを作成して、圧縮されたコアダンプデータを当該ファイルに書き込んでゆく。例えば、最初は図２に示したようにファイルＦ１にコアダンプデータが記憶され、以後、コアダンプ処理が行われる度にファイルＦ２，ファイルＦ３，……，のようにファイルが順次作成されてコアダンプデータが蓄積されてゆく。
【００２９】
次に、上述した契機▲２▼が発生した場合について説明する。システムがハングアップするなどして、ユーザがフロントパネル５１からシステムに指示を行っても応答が無いことに気付いた場合、ユーザはフロントパネル５１上のリセットボタンを押下する。これによって、ＰＵＩ５０はＮＭＩ信号をＣＰＵ１０に対して送出する。ＣＰＵ１０はこのＮＭＩ信号を契機としてシステムプログラム２１上の割り込み処理を起動させ、この割り込み処理の中で汎用レジスタ６１に固定値０ｘ“ａ”を書き込んでコアダンプ要求を設定する。この後、ＰＵＩ５０はＮＭＩ要求を送出してから一定時間後にリセット信号をシステム内の各部へ送出してハードウェアリセットを行う。このハードウェアリセットにより、システム内の各部が正常な状態に復帰し、ＲＯＭ３０の先頭番地からブートプログラム３１が走行する。ブートプログラム３１は契機▲１▼の場合と同様にして、既存のブート処理を行ったのち、フラグ４１および汎用レジスタ６１の内容を調べ、汎用レジスタ６１の保持内容が０ｘ“ａ”であることからコアダンププログラム３２にコアダンプ処理を行わせる。この後は、ＯＳ及びアプリケーションが順次立ち上がり、アプリケーションプログラム２２がコアダンプデータの蓄積処理を行う。
【００３０】
次に、上述した契機▲３▼が発生した場合について説明する。デバッグボート７０が１回目のハードウェアリセット指示を行ってブートプログラム３１が起動すると、ブートプログラム３１はＲＡＭ４０上のカウンタの値を“１”増加させ、その値が“２”になっているかどうか調べる。この場合はカウンタの値が“１”であるため、ブートプログラム３１は引き続いて既存のブート処理を実行する。このブート処理の最中にデバッグボード７０から２回目のハードウェアリセット指示があると、当該指示に対応したリセット動作の後に再びブートプログラム３１が起動される。これにより、ブートプログラム３１はＲＡＭ４０上のカウンタの値に“１”を加算し、カウンタの値が“２”になっていることからデバッグボード７０からの連続するリセット指示であることを検出し、フラグ４１に０ｘ“ＡＡ”を書き込んでコアダンプ要求を設定したのち、カウンタの値を“０”に初期化する。次に、ブートプログラム３１は１回目のハードウェアリセットの場合と同様に既存のブート処理を行う。このブート処理が完了すると、ブートプログラム３１は契機▲１▼ないし契機▲２▼の場合と同様にしてフラグ４１及び汎用レジスタ６１を調べ、フラグ４１の内容からコアダンプ要求を検出してコアダンププログラム３２にコアダンプを行わせる。この後は、ＯＳとアプリケーションが順次立ち上がって、アプリケーションプログラム２２がコアダンプデータの蓄積処理を行う。
【００３１】
次に、上述した契機▲４▼が発生した場合について説明する。アプリケーションプログラム２２にバグが存在し、その処理の途中で“０”番地にジャンプしてしまったものとする。このジャンプ命令の実行に際してスタック１１には“０”が設定される。前述したように“０”番地はブートプログラム３１の先頭番地でもあるため、ＣＰＵ１０の処理はブートプログラム３１に移行する。ブートプログラム３１はスタック１１の内容を参照してその内容が“０”であることを検出し、“０”番地へのジャンプという通常有りえないシーケンスで自身が起動されたことを知る。そこで、ブートプログラム３１はフラグ４１に０ｘ“ＡＡ”を書き込んでコアダンプ要求を設定する。この後、ブートプログラム３１は既存のブート処理を行ったのち、フラグ４１にコアダンプ要求が設定されていることから、コアダンププログラム３２を起動してコアダンプ処理を行う。この後、ＯＳとアプリケーションが順次立ち上がって、アプリケーションプログラム２２がコアダンプデータの蓄積処理を行う。
【００３２】
以上のように、コアダンプ機能をブートプログラム３１から起動されるコアダンププログラム３２にまとめることで、ＲＡＭ４０上の領域を無駄に消費することがなくなるほか、基本的にブートプログラム３１についてのみコアダンプ機能に関わるプログラム開発を行えば良くなるため、プログラム開発上の負担を軽減することができる。
【００３３】
また、上述したように、コアダンプの契機は必ずしもアプリケーションプログラムの実行時に判明するものばかりではない。すなわち、契機▲２▼や契機▲３▼はアプリケーションプログラムの走行とは非同期的に生じるため、アプリケーションがこれら契機を把握することはできず、ブートプログラム３１の実行時に初めて検出できる。また、契機▲４▼は“０”番地へのジャンプでブートプログラム３１が起動されて初めて判るものである。そこで本実施形態では、コアダンプの要求が存在することをフラグ４１ないし汎用レジスタ６１に残しておき、ブートプログラム３１が起動された時点でこれらの情報からコアダンプの要求を検出してコアダンプ処理を行っている。したがって、コアダンプ機能をブートプログラム３１側で集中的に管理することができる。
【００３４】
【発明の効果】
以上説明したように、本発明では、異常の発生を示す事象を検出した時点でコアダンプの要求を示す要求データを設定しておき、異常発生に伴って起動されるリブート処理が完了してから当該要求データを調べて、コアダンプが要求されていればコアダンプを行うようにしている。これにより、リブート処理でシステムが正常に立ち上がった状態でコアダンプが行われるため、ＯＳさえ暴走するような危機的な状況に陥った場合にも、コアダンプ処理を確実に行うことができる。また、システムの様々な状態において生じるコアダンプ要求をいったん要求データとして設定しておき、リブート時にコアダンプの要求を判断しているため、コアダンプ機能をブートプログラム等で集中管理することができる。
【００３５】
また、請求項２記載の発明では、主記憶上の所定位置に設けられたフラグによってコアダンプ要求を設定しているため、ハードウェアリセットの介在を必要としない異常が発生したような場合において、特別なハードウェアを設けることなくリブート後のコアダンプを実現することができる。
また、請求項３記載の発明では、ハードウェアリセットで保持内容が影響されない不揮発性媒体を用いてコアダンプ要求を設定しているため、ハングアップなどによってハードウェアリセットが必要となるような状況に陥った場合であっても、その後のリブート時においてコアダンプを確実に行うことができる。
【００３６】
また、請求項４記載の発明では、プログラム内でジャンプが発生したときのジャンプ先アドレスを記憶しておき、このジャンプ先アドレスがプログラムの走行するはずのないアドレスであるときにコアダンプ要求を設定するようにしている。これにより、プログラムのバグによってしばしば発生する“０”番地へのジャンプといった事象を捉えてコアダンプを行うことができる。
また、請求項５記載の発明では、外部記憶装置上の固定領域にコアダンプが行われ、この固定領域に書き出される主記憶の内容を外部記憶装置上の蓄積領域へ蓄積させるようにしている。これにより、異常な状態が何度も生じるような場合に、採取されたコアダンプを総合して原因究明にあてることができる。
また、請求項６記載の発明では、蓄積手段の機能をアプリケーションプログラムへ組み込み、採取されたコアダンプに圧縮処理を施してから蓄積させるようにしている。これによって、圧縮処理をブートプログラムへ組み込むのが難しいという問題に対処しつつ、コアダンプを蓄積してゆくのに必要となる記憶領域を削減することができる。
【図面の簡単な説明】
【図１】  本発明の一実施形態によるコンピュータシステムの構成を示すブロック図である。
【図２】  同実施形態におけるＨＤＤ２０上の領域割り当てを示す説明図である。
【符号の説明】
１０……ＣＰＵ、１１……スタック、２０……ＨＤＤ、２１……システムプログラム、２２……アプリケーションプログラム、２３……固定領域、２４……蓄積領域、３０……ＲＯＭ、３１……ブートプログラム、３２……コアダンププログラム、４０……ＲＡＭ、４１……フラグ、５０……ＰＵＩ、５１……フロントパネル、６０……ＲＴＣ、６１……汎用レジスタ、７０……デバッグボード。
【図１】
0004269362.tif 000002
【図２】
0004269362.tif 000003