JP4269362B2 - Computer system - Google Patents
Computer system Download PDFInfo
- Publication number
- JP4269362B2 JP4269362B2 JP27032498A JP27032498A JP4269362B2 JP 4269362 B2 JP4269362 B2 JP 4269362B2 JP 27032498 A JP27032498 A JP 27032498A JP 27032498 A JP27032498 A JP 27032498A JP 4269362 B2 JP4269362 B2 JP 4269362B2
- Authority
- JP
- Japan
- Prior art keywords
- core dump
- program
- request
- contents
- flag
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Description
【0001】
【発明の属する技術分野】
本発明はコンピュータシステムに関し、特に、システム内でハングアップや異常が発生した場合に、主記憶装置の内容をハードディスク(以下、HDDという)等の大容量記憶装置へ書き出すコアダンプ処理に関するものである。
【0002】
【従来の技術】
ワークステーション等のコンピュータシステムでは、システムがハングアップしたことを検出した場合や何らかの原因でアプリケーションが異常終了したような場合に、異常発生時点で主記憶装置に格納されているデータをHDDといったより大容量の外部記憶装置へ転送することが行われている。こうした処理は一般にコアダンプ処理などと呼ばれている。こうしたコアダンプ処理はシステムを異常な状態から救済する目的で為されるほか、救済措置が奏功しなかったような場合は、原因究明のために行われる事後的な解析においてコアダンプされたデータが利用されることになる。
【0003】
【発明が解決しようとする課題】
ところで、従来のコンピュータシステムでは異常が発生した時点ですぐにコアダンプ処理を行っている。すなわち、OS(オペレーティングシステム)が監視タイマ等でハングアップを検出するなど自ら異常を検出するか、あるいは、アプリケーションやハードウェアから異常の報告を受けると、OSは異常処理の一環としてコアダンプ処理を行う。その後、OSはコアダンプ処理を含む異常処理がすべて完了した時点でシステムをリブート(再起動)させている。
【0004】
このように、従来のコンピュータシステムではOSが正常に動作していることを前提としてコアダンプ処理が行われている。しかしながら、異常が発生するような状況下ではシステム内で何が起きているか全く予測できないこともあり、場合によってはOSすら暴走するような状況に陥っていることも考えられる。特に、コンピュータシステムが組み込み機器などに用いられる場合は、過酷な環境下でシステムを動作させる必要が生じることも多々あり、OSが正常に動作できない状況になってしまう蓋然性が高い。
【0005】
以上の通り、従来のような方法を採用していたのではコアダンプ処理を常に確実に行える保証が得られず、コアダンプ処理の結果をもとに行われる救済措置や原因究明なども有効に行えないといった問題がある。
本発明は上記の点に鑑みてなされたものであり、その目的は、OSすら暴走するような危機的な状況が発生した場合であっても、コアダンプ処理を確実に行ってコアダンプされた内容の信頼性を向上させられるコンピュータシステムを提供することにある。
【0006】
【課題を解決するための手段】
以上の課題を解決するために、請求項1記載の発明は、システム内で異常が発生した場合に該システムの主記憶の内容を外部記憶装置へ書き出すコアダンプを行うコンピュータシステムにおいて、前記コアダンプの要求の有無を表す要求データを保持する保持手段と、前記異常の発生を示す事象を検出した時点で、前記コアダンプの要求を示す要求データを前記保持手段に設定する設定手段と、前記異常の発生に伴って起動されるシステムのリブート処理が完了してから前記要求データを調べ、該要求データが前記コアダンプの要求を示していることを条件として前記コアダンプを行うコアダンプ手段とを具備することを特徴としている。また、請求項2記載の発明は、請求項1記載の発明において、前記保持手段として、前記主記憶上の所定位置に設けられたフラグを有することを特徴としている。
また、請求項3記載の発明は、請求項1又は2記載の発明において、前記保持手段として、システムのハードウェアリセットによって保持内容が影響を受けない不揮発性媒体を有することを特徴としている。
【0007】
また、請求項4記載の発明は、請求項1〜3の何れかの項記載の発明において、システム上を走行するプログラムでジャンプが発生したときのジャンプ先アドレスを記憶する記憶手段を有し、前記設定手段は、前記ジャンプ先アドレスが前記プログラムの走行するはずのないアドレスであることを検出して、前記要求データを前記保持手段に設定することを特徴としている。
また、請求項5記載の発明は、請求項1〜4の何れかの項記載の発明において、前記コアダンプ手段は、前記主記憶の内容を前記外部記憶装置上の固定領域に書き出すものであって、該固定領域に書き出された前記主記憶の内容を前記外部記憶装置上の蓄積領域に蓄積してゆく蓄積手段をさらに有することを特徴としている。
また、請求項6記載の発明は、請求項5記載の発明において、前記蓄積手段は、前記システム上を走行するアプリケーションプログラムに組み込まれ、前記主記憶の内容に圧縮処理を施してから前記外部記憶装置へ蓄積させてゆくことを特徴としている。
【0008】
【発明の実施の形態】
以下、図面を参照して本発明の一実施形態について説明する。
まず最初に本発明についてその概要を説明する。従来の技術における問題点を考察して分かることは、コアダンプ機能を実現するプログラムはそれまでのシステム状態にかかわらず正常に動作する必要性があるほか、OSを介在することなく動作可能なものでなければならない。そのためには、電源投入直後などのように未だOSも立ち上がっていない状態、すなわち、システムのブート時という初期化フェーズでコアダンプ処理を行う必要があることになる。
【0009】
こうしたことから本発明は、従来のように異常発生時点ですぐコアダンプするのではなく、リブート時にコアダンプ処理を行うようにしている。ここで、コアダンプの要求はシステムの様々な状態において生じうる。そのため、本発明ではコアダンプ要求のための情報を様々な方法を用いてシステム上に残しておいた上でブートプログラムを起動し、当該プログラムによるリブート動作でシステムが正常に立ち上がってからコアダンププログラムを起動してコアダンプを行っている。
【0010】
ちなみに、ブートプログラム側にコアダンプ機能を持たせるのではなく、システム上で走行するOSを含めた全てのプログラムにコアダンプ機能を持たせることも考えられる。しかし、システム上では、ユーザが通常走行させる一般的なアプリケーションプログラム,システムの初期設定及び状態確認を行うサービス用プログラム,生産時にシステムを検査するために使用する検査プログラムなど、様々なアプリケーションプログラムが走行する。これらプログラム全てにコアダンプ機能を重複させて組み込むことは、主記憶領域を無駄に消費するのみならず、アプリケーションを開発する上での負担も大きくなる。この点、コアダンプ機能を一つのコアダンププログラムとしてまとめれば主記憶を浪費することは無くなるが、アプリケーション全てにコアダンププログラムをリンクさせる必要があるため、やはりアプリケーション開発上の負担となる。したがってコアダンプ機能はブートプログラムに組み込むのが最適である。
【0011】
さて、図1は本実施形態によるコンピュータシステムの構成を示すブロック図である。同図において、CPU(中央処理装置)10は、後述するROM30やRAM40に格納された各種プログラムを実行することでシステム内の各部の動作を統括制御する。このCPU10は一般的なマイクロプロセッサなどと同様にプログラムカウンタ,レジスタ類を備えているほか、スタック11を具備している。CPU10はジャンプ命令を実行する度にジャンプ先のアドレスをスタック11に設定する構成になっている。
【0012】
HDD20はRAM40(後述)上にロードされるシステムプログラム21及びアプリケーションプログラム22を予め格納している。これらのうち、システムプログラム21はOSに相当するものである。また、アプリケーションプログラム22は、アプリケーションとしての通常の動作を行うほか、コアダンプ処理が終了した後、採取されたコアダンプデータに圧縮処理を施してHDD20上に蓄積してゆく機能を持っている。その際、ブートプログラム31がコアダンププログラム32を起動してコアダンプ処理を行った場合は、その旨をシステムプログラム21に通知するようにしており、システムプログラム21は当該通知に基づいてコアダンプが行われたかどうかをRAM40上にレコードとして残しておく。アプリケーションプログラム22はこのレコードの内容を参照することで、コアダンプが実施されたかどうを知ることができる。なお、かかる蓄積機能をブートプログラム31でなくアプリケーションプログラム22に組み込む理由は、圧縮処理というプログラムサイズの大きな処理が含まれているためであって、こうした機能をブートプログラム側に含ませて主記憶上に常駐させることが困難であることによる。したがって、圧縮処理を省くなどしてプログラムサイズを小さくすれば、ブートプログラム側に蓄積機能を持たせることも可能である。
【0013】
このほか、HDD20には図2に示すような固定領域23及び蓄積領域24が設けられている。固定領域23はコアダンプ処理によってRAM40の内容の一部ないし全部が転送される領域であって、固定領域23のHDD上における記憶位置は予め決められている。そのため、コアダンプ処理が行われると固定領域23の内容はその都度書き換えられることになる。一方、蓄積領域24はコアダンプの度に更新される固定領域23の内容を順次蓄積してゆくための領域であって、アプリケーションプログラム22の管轄下にあるファイルシステムで構成されるため、実際にはHDD20上の任意の領域に設ければ良い。蓄積領域24を設ける主たる理由は、異常な状態が何度も生じるような場合に採取したコアダンプをすべて保存しておき、これらを総合して原因解析を行うためである。
【0014】
次に、ROM(リードオンリーメモリ)30は、システムをブートさせるためのブートプログラム31とコアダンプ処理を行うコアダンププログラム32を記憶している。なお、本実施形態においてはブートプログラム31の先頭番地が0x“a0000000”番地(0xは16進数を意味する標記)であるものとする。ここで、本実施形態によるコンピュータシステムでは0x“a0000000”番地と“0”番地が等価になっている。すなわち、論理的には命令アドレスとして32ビットの値を指定することができるが、CPU10は命令アドレスの上位4ビットを常に“0”と見なす造りになっており、x“a0000000”番地は“0”番地と等しく扱われる。ただ、ブートプログラム31へジャンプする際にジャンプ先として“0”番地を指定すると、プログラムにバグがあって“0”番地へジャンプした場合と区別することができなくなる。そこで本実施形態では、システムプログラム21等が意図的にブートプログラム31へジャンプする場合には、0x“a0000000”番地へジャンプするようにプログラムを作成している。
【0015】
次に、RAM(ランダムアクセスメモリ)40は、ブートプログラム31がHDD20からロードするシステムプログラム21及びアプリケーションプログラム22を記憶するほか、これら各プログラムが使用する変数などを記憶する。これに加えて、RAM40は予め決められた所定位置に1バイトのフラグ41(詳細については後述)を記憶している。
次に、PUI(パネルユーザインタフェース)50は、ユーザがフロントパネル51を操作したときの操作内容を当該フロントパネル51から受け取ってCPU10へ伝達するインタフェース回路である。例えば、PUI50はフロントパネル51上のリセットボタン(図示省略)が押されたことを知り、CPU10に対してNMI信号(Non-Maskable-Interrupt;マスク不可能な割り込み要求)を送出する。一般的なマイクロプロセッサと同様に、本実施形態ではCPUに対する割り込みとしてマスク可能な割り込み(いわゆるIRQ)とマスク不可能な割り込みがあるが、このNMI信号は最も優先度の高い割り込み要求である。また、PUI50はNMI信号をCPU10へ送出してから一定時間が経過した後にシステム各部へリセット信号を送出する機能も持っている。
【0016】
次に、RTC(リアルタイムクロック)60はCPU10の制御下で動作するカレンダ用の集積回路であって、一般的なカレンダ機能を有するほか、汎用的に使用することの可能な汎用レジスタ61を備えている。汎用レジスタ61の内容はCPU10が読み書き可能であり、また、この汎用レジスタ61はバッテリバックアップされており、ハードウェアリセットを行ってもその内容が保持されるようになっている。なお、本実施形態では汎用レジスタ61が4ビットで構成されているものとする。
次に、デバッグボード70はシステムの開発段階でのみ接続されるデバッグ専用の回路である。
【0017】
ところで、前述のようにコアダンプの要求は種々のシステム状態において生じうるが、本実施形態では以下に述べる事象を契機としてコアダンプ要求を行っている。
〔契機▲1▼ 〕プログラムによるコアダンプ付きリブート要求
システムプログラム21やアプリケーションプログラム22はプログラム走行中にソフトウェア的な異常を検出すると、システムプログラム21内に予め用意されている関数(以下ではこれを SystemDown 関数とする)を呼び出す。この SystemDown 関数は、RAM40上のフラグ41に所定値を書き込み、それによってコアダンプ要求を設定するようにしている。この所定値はどのような値でも良いが、本実施形態ではコアダンプ要求が存在しない場合に“0”が設定されるものとし、コアダンプ要求を設定する場合には“0”以外の任意の固定値として0x“AA”を書き込むようにしている。また、 SystemDown 関数はフラグ41へ所定値を格納した後に、ブートプログラム31の先頭番地(すなわち、0x“a0000000”番地)へジャンプしてリブート処理を起動させる。
【0018】
〔契機▲2▼〕フロントパネルからのリセット指示
システムの動作が異常であることをユーザが認識したような場合、ユーザはフロントパネル51に設置されているリセットボタンを押下し、システムに対してハードウェアリセットの指示を行う。前述したように、リセットボタンの押下に伴ってPUI50がNMI信号を発生させるため、このNMI信号が割り込み処理を担うシステムプログラム21へのコアダンプ要求の契機となる。
【0019】
〔契機▲3▼ 〕デバッグボードからの連続2回のリセット指示
先に説明したように、システムの開発段階では動作確認のためにデバッグボード70が接続される。そこで、デバッグボード70からコアダンプすべき状況(即ち、異常発生時に対応した状況)を意図的に再現可能とするために、デバッグボート70からハードウェアリセットの指示が2回連続して行われた場合にこれをコアダンプ要求と見なす。なお、デバッグボード70から2回連続してリセット指示があるかどうかはブートプログラム31が判断する。すなわち、ブートプログラム31はRAM40上にカウンタを設けるようにしており、起動される度にカウンタの値を“1”増加させるほか、その後に行われるコアダンプ処理の直前で、カウンタの値が“2”になっていることを検出してコアダンプ要求を発生させる処理と、カウンタの値を“0”に初期化する処理を順次行うようにしている。なお、2回連続という条件を付したのは、コアダンプすべき状況にない場合でもデバッグボード70がハードウェアリセットを出す場合があるためである。
【0020】
〔契機▲4▼ 〕“0”番地へのジャンプ
アプリケーションやOSが正しくプログラミングされている限り、プログラムが“0”番地へジャンプすることは通常考えられない。しかし、アプリケーション等にバグが存在すると“0”番地にジャンプするような状況が生じうる。例えば、関数呼び出しを行う場合は呼び出される関数の先頭アドレスをポインタとして指定することになる。その場合、プログラムにバグがあってポインタに正しい値が設定されないと、デフォルトで設定される“0”がポインタに設定されてしまい、結果的に“0”番地(即ち、ブートプログラム31の先頭アドレス)にジャンプしてしまう。こうしたことから、ブートプログラム31は自身が“0”番地からのジャンプによって起動されたことを検出した場合は、これをコアダンプ要求としている。
【0021】
次に、リブート後にコアダンプを行うための実現手段について説明する。
〔実現手段▲1▼〕
この実現手段では少なくともOSが正常に動いている状態を前提としており、前述した契機▲1▼に対応するものである。当該実現手段では、 SystemDown 関数が設定するフラグ41を参照してその内容がx“AA”である場合にコアダンプ要求が存在していると判断する。上述したように、 SystemDown 関数は最終的に0x“a0000000”番地へ分岐してソフトウェア的にリブート処理を起動させている。換言すれば、前述の契機▲1▼ではハードウェアリセットを媒介としていないため、RAM40の記憶内容を信用することができる。したがって、RAM40上にフラグ41を設け、異常発生時点でフラグ41に値を設定し、リブート後に当該領域の内容に従ってコアダンプ処理の要否を判断しても問題はない。また、この実現手段では、フラグ41の他にもエラー時における種々のデータを併せてRAM40上に残すことができるという利点がある。
【0022】
〔実現手段▲2▼〕
この実現手段は、ハングアップしている場合やOSが暴走している場合などのように、ハードウェアリセットを経由させてからリブートする必要があるときに用いられる実現手段である。つまり、この実現手段▲2▼は上述した契機▲2▼や契機▲3▼のためのものである(もっとも、契機▲1▼の場合などに用いることも可能である)。前述したように、ハードウェアリセットを行うと、リセット動作と命令実行動作が重なりあってRAM40が予期せず書き換えられるなどの恐れがあり、その内容は信用できないものとなる。したがって、こうした場合にはRAM40上のフラグ41を用いている実現手段▲1▼が使用できない。
【0023】
こうしたことから、本実現手段▲2▼ではRTC60内に設けた汎用レジスタ61を利用している。例えば、ユーザがフロントパネル51のリセットボタンを押下する契機▲2▼の場合、システムプログラム21はNMI信号による割り込み処理の過程で、汎用レジスタ61に固定値として例えばx“a”を書き込んでおく。この後、NMI信号から一定時間後にPUI50がシステム各部にハードウェアリセットをかけるが、この場合にも汎用レジスタ61の内容は不変である。したがって、ハードウェアリセット後に起動されるブートプログラム31は、汎用レジスタ61の内容が0x“a”であればコアダンプ要求が存在するものと見なす。このほか、ブートプログラム31はコアダンプ処理を行ったのちに、汎用レジスタ61の内容を“0”に初期化して、次のコアダンプ要求が設定される場合に備える。
【0024】
なお、実際の動作過程では、ブートプログラム31はソフトウェア的に起動さされたのかハードウェア的に起動されたかに依らず、フラグ41と汎用レジスタ61の双方を常に調べるようにしている。つまり、ハードウェア的に起動されたのであれば汎用レジスタ61にはコアダンプ要求が設定されており、また、ソフトウェア的に起動されたのであれば汎用レジスタ61にコアダンプ要求は無くフラグ41にだけコアダンプ要求が設定されている。また、不揮発性メモリなどのバッテリバックアップされた記憶手段を持つ構成とすることで、こうした記憶手段を汎用レジスタ61の代わりに用いることができる。
【0025】
〔実現手段▲3▼〕
この実現手段は、“0”番地へジャンプした結果としてブートプログラム31が起動された場合に用いられるものであって、上述した契機▲4▼に対応する実現手段である。本実現手段▲3▼では、ブートプログラム31がスタック11に保持されたジャンプ先アドレスを参照し、その内容が“0”であれば“0”番地からのジャンプであると見なし、コアダンププログラム32を起動してコアダンプ処理を行うようにしている。
【0026】
次に、上記構成によるコンピュータシステムで行われるコアダンプ処理について説明する。なお、以下ではシステムプログラム21及びアプリケーションプログラム22が既にRAM40上に読み込まれており、OSやアプリケーションが走行して状況にあるものとする。
【0027】
まず、上述した契機▲1▼が発生した場合について説明する。アプリケーションプログラム22が実行中に何らかの異常を検出した場合、アプリケーションプログラム22はシステムプログラム21内の SystemDown 関数を呼び出す。これによって、システムプログラム21はフラグ41に0x“AA”を書き込んでコアダンプ要求を設定したのち、ブートプログラム31の先頭番地へジャンプする。ブートプログラム31は、既存のブート処理を実行することにより、システムを正常に立ち上げるために最低限必要な初期化処理等を行う。次に、ブートプログラム31は、フラグ41および汎用レジスタ61の内容をそれぞれ調べ、フラグ41に0x“AA”が設定されることを検出してコアダンプ要求を認識し、コアダンププログラム32を起動してRAM40の内容をHDD20上の固定領域23へ順次書き出してゆく。
【0028】
このコアダンプ処理の後、ブートプログラム31はフラグ41及び汎用レジスタ61をクリアするとともに、コアダンプを行ったことをシステムプログラム21に通知するデータをRAM40上に設定する。次に、ブートプログラム31はシステムプログラム21をHDD20からRAM40上にロードし、当該システムプログラム21へ処理を委譲してOSを立ち上げる。この後、システムプログラム21はコアダンプを行ったことを示すレコードを設定し、アプリケーションプログラム22をHDD20から読み出して起動させる。アプリケーションプログラム22はアプリケーション本来の処理を行う前に、上記レコードからコアダンプが行われたことを知り、固定領域23上に採取されたコアダンプデータを読み出してこれに圧縮処理を施したのち、蓄積領域24上に新たにファイルを作成して、圧縮されたコアダンプデータを当該ファイルに書き込んでゆく。例えば、最初は図2に示したようにファイルF1にコアダンプデータが記憶され、以後、コアダンプ処理が行われる度にファイルF2,ファイルF3,……,のようにファイルが順次作成されてコアダンプデータが蓄積されてゆく。
【0029】
次に、上述した契機▲2▼が発生した場合について説明する。システムがハングアップするなどして、ユーザがフロントパネル51からシステムに指示を行っても応答が無いことに気付いた場合、ユーザはフロントパネル51上のリセットボタンを押下する。これによって、PUI50はNMI信号をCPU10に対して送出する。CPU10はこのNMI信号を契機としてシステムプログラム21上の割り込み処理を起動させ、この割り込み処理の中で汎用レジスタ61に固定値0x“a”を書き込んでコアダンプ要求を設定する。この後、PUI50はNMI要求を送出してから一定時間後にリセット信号をシステム内の各部へ送出してハードウェアリセットを行う。このハードウェアリセットにより、システム内の各部が正常な状態に復帰し、ROM30の先頭番地からブートプログラム31が走行する。ブートプログラム31は契機▲1▼の場合と同様にして、既存のブート処理を行ったのち、フラグ41および汎用レジスタ61の内容を調べ、汎用レジスタ61の保持内容が0x“a”であることからコアダンププログラム32にコアダンプ処理を行わせる。この後は、OS及びアプリケーションが順次立ち上がり、アプリケーションプログラム22がコアダンプデータの蓄積処理を行う。
【0030】
次に、上述した契機▲3▼が発生した場合について説明する。デバッグボート70が1回目のハードウェアリセット指示を行ってブートプログラム31が起動すると、ブートプログラム31はRAM40上のカウンタの値を“1”増加させ、その値が“2”になっているかどうか調べる。この場合はカウンタの値が“1”であるため、ブートプログラム31は引き続いて既存のブート処理を実行する。このブート処理の最中にデバッグボード70から2回目のハードウェアリセット指示があると、当該指示に対応したリセット動作の後に再びブートプログラム31が起動される。これにより、ブートプログラム31はRAM40上のカウンタの値に“1”を加算し、カウンタの値が“2”になっていることからデバッグボード70からの連続するリセット指示であることを検出し、フラグ41に0x“AA”を書き込んでコアダンプ要求を設定したのち、カウンタの値を“0”に初期化する。次に、ブートプログラム31は1回目のハードウェアリセットの場合と同様に既存のブート処理を行う。このブート処理が完了すると、ブートプログラム31は契機▲1▼ないし契機▲2▼の場合と同様にしてフラグ41及び汎用レジスタ61を調べ、フラグ41の内容からコアダンプ要求を検出してコアダンププログラム32にコアダンプを行わせる。この後は、OSとアプリケーションが順次立ち上がって、アプリケーションプログラム22がコアダンプデータの蓄積処理を行う。
【0031】
次に、上述した契機▲4▼が発生した場合について説明する。アプリケーションプログラム22にバグが存在し、その処理の途中で“0”番地にジャンプしてしまったものとする。このジャンプ命令の実行に際してスタック11には“0”が設定される。前述したように“0”番地はブートプログラム31の先頭番地でもあるため、CPU10の処理はブートプログラム31に移行する。ブートプログラム31はスタック11の内容を参照してその内容が“0”であることを検出し、“0”番地へのジャンプという通常有りえないシーケンスで自身が起動されたことを知る。そこで、ブートプログラム31はフラグ41に0x“AA”を書き込んでコアダンプ要求を設定する。この後、ブートプログラム31は既存のブート処理を行ったのち、フラグ41にコアダンプ要求が設定されていることから、コアダンププログラム32を起動してコアダンプ処理を行う。この後、OSとアプリケーションが順次立ち上がって、アプリケーションプログラム22がコアダンプデータの蓄積処理を行う。
【0032】
以上のように、コアダンプ機能をブートプログラム31から起動されるコアダンププログラム32にまとめることで、RAM40上の領域を無駄に消費することがなくなるほか、基本的にブートプログラム31についてのみコアダンプ機能に関わるプログラム開発を行えば良くなるため、プログラム開発上の負担を軽減することができる。
【0033】
また、上述したように、コアダンプの契機は必ずしもアプリケーションプログラムの実行時に判明するものばかりではない。すなわち、契機▲2▼や契機▲3▼はアプリケーションプログラムの走行とは非同期的に生じるため、アプリケーションがこれら契機を把握することはできず、ブートプログラム31の実行時に初めて検出できる。また、契機▲4▼は“0”番地へのジャンプでブートプログラム31が起動されて初めて判るものである。そこで本実施形態では、コアダンプの要求が存在することをフラグ41ないし汎用レジスタ61に残しておき、ブートプログラム31が起動された時点でこれらの情報からコアダンプの要求を検出してコアダンプ処理を行っている。したがって、コアダンプ機能をブートプログラム31側で集中的に管理することができる。
【0034】
【発明の効果】
以上説明したように、本発明では、異常の発生を示す事象を検出した時点でコアダンプの要求を示す要求データを設定しておき、異常発生に伴って起動されるリブート処理が完了してから当該要求データを調べて、コアダンプが要求されていればコアダンプを行うようにしている。これにより、リブート処理でシステムが正常に立ち上がった状態でコアダンプが行われるため、OSさえ暴走するような危機的な状況に陥った場合にも、コアダンプ処理を確実に行うことができる。また、システムの様々な状態において生じるコアダンプ要求をいったん要求データとして設定しておき、リブート時にコアダンプの要求を判断しているため、コアダンプ機能をブートプログラム等で集中管理することができる。
【0035】
また、請求項2記載の発明では、主記憶上の所定位置に設けられたフラグによってコアダンプ要求を設定しているため、ハードウェアリセットの介在を必要としない異常が発生したような場合において、特別なハードウェアを設けることなくリブート後のコアダンプを実現することができる。
また、請求項3記載の発明では、ハードウェアリセットで保持内容が影響されない不揮発性媒体を用いてコアダンプ要求を設定しているため、ハングアップなどによってハードウェアリセットが必要となるような状況に陥った場合であっても、その後のリブート時においてコアダンプを確実に行うことができる。
【0036】
また、請求項4記載の発明では、プログラム内でジャンプが発生したときのジャンプ先アドレスを記憶しておき、このジャンプ先アドレスがプログラムの走行するはずのないアドレスであるときにコアダンプ要求を設定するようにしている。これにより、プログラムのバグによってしばしば発生する“0”番地へのジャンプといった事象を捉えてコアダンプを行うことができる。
また、請求項5記載の発明では、外部記憶装置上の固定領域にコアダンプが行われ、この固定領域に書き出される主記憶の内容を外部記憶装置上の蓄積領域へ蓄積させるようにしている。これにより、異常な状態が何度も生じるような場合に、採取されたコアダンプを総合して原因究明にあてることができる。
また、請求項6記載の発明では、蓄積手段の機能をアプリケーションプログラムへ組み込み、採取されたコアダンプに圧縮処理を施してから蓄積させるようにしている。これによって、圧縮処理をブートプログラムへ組み込むのが難しいという問題に対処しつつ、コアダンプを蓄積してゆくのに必要となる記憶領域を削減することができる。
【図面の簡単な説明】
【図1】 本発明の一実施形態によるコンピュータシステムの構成を示すブロック図である。
【図2】 同実施形態におけるHDD20上の領域割り当てを示す説明図である。
【符号の説明】
10……CPU、11……スタック、20……HDD、21……システムプログラム、22……アプリケーションプログラム、23……固定領域、24……蓄積領域、30……ROM、31……ブートプログラム、32……コアダンププログラム、40……RAM、41……フラグ、50……PUI、51……フロントパネル、60……RTC、61……汎用レジスタ、70……デバッグボード。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a computer system, and more particularly to a core dump process for writing the contents of a main storage device to a mass storage device such as a hard disk (hereinafter referred to as HDD) when a hang-up or abnormality occurs in the system.
[0002]
[Prior art]
In a computer system such as a workstation, when it is detected that the system has hung up or when an application terminates abnormally for some reason, the data stored in the main storage device at the time of occurrence of the abnormality is larger than that of an HDD. Transferring to a capacity external storage device is performed. Such processing is generally called core dump processing. Such core dump processing is performed for the purpose of relieving the system from an abnormal state, and if the remedial measures are not successful, the core dumped data is used in a subsequent analysis to investigate the cause. Will be.
[0003]
[Problems to be solved by the invention]
By the way, in a conventional computer system, a core dump process is performed immediately when an abnormality occurs. That is, when the OS (operating system) detects an abnormality by itself, such as detecting a hang-up by a monitoring timer or the like, or receives an abnormality report from an application or hardware, the OS performs a core dump process as part of the abnormality process. . Thereafter, the OS reboots (restarts) the system when all the abnormal processes including the core dump process are completed.
[0004]
Thus, in the conventional computer system, the core dump process is performed on the assumption that the OS is operating normally. However, under circumstances where an abnormality occurs, what is happening in the system may not be predicted at all, and in some cases, even an OS may run out of control. In particular, when a computer system is used for an embedded device or the like, it is often necessary to operate the system in a harsh environment, and there is a high probability that the OS will not operate normally.
[0005]
As described above, using the conventional method does not guarantee that core dump processing can always be performed reliably, and it is not possible to effectively perform remedies or cause investigations based on the results of core dump processing. There is a problem.
The present invention has been made in view of the above points. The purpose of the present invention is to ensure that the core dump process is performed and the core dump is performed even in the case of a critical situation where even the OS runs away. An object is to provide a computer system capable of improving reliability.
[0006]
[Means for Solving the Problems]
In order to solve the above problems, the invention according to
The invention described in
[0007]
The invention according to claim 4 has storage means for storing a jump destination address when a jump occurs in the program running on the system in the invention according to any one of
The invention according to
According to a sixth aspect of the present invention, in the fifth aspect of the present invention, the storage unit is incorporated in an application program that runs on the system, compresses the contents of the main memory, and then stores the external memory. It is characterized by being accumulated in the device.
[0008]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
First, the outline of the present invention will be described. It can be understood by considering the problems in the prior art that the program that realizes the core dump function needs to operate normally regardless of the system state up to that point, and can operate without intervention of the OS. There must be. For this purpose, it is necessary to perform the core dump process in the state where the OS has not yet started up, such as immediately after power-on, that is, in the initialization phase when the system is booted.
[0009]
For this reason, the present invention does not perform a core dump immediately when an abnormality occurs as in the prior art, but performs a core dump process at the time of reboot. Here, core dump requests can occur in various states of the system. Therefore, in the present invention, the information for core dump request is left on the system using various methods, the boot program is started, and the core dump program is started after the system is normally booted by the reboot operation by the program. And doing a core dump.
[0010]
Incidentally, it is also conceivable that all programs including the OS running on the system are provided with a core dump function instead of having a core dump function on the boot program side. However, on the system, various application programs such as a general application program that the user normally runs, a service program that performs initial setting and status check of the system, and an inspection program that is used to inspect the system during production run. To do. Incorporating the core dump function in duplicate in all of these programs not only wastes the main storage area, but also increases the burden on developing applications. In this regard, if the core dump function is combined as a single core dump program, main memory is not wasted, but it is necessary to link the core dump program to all the applications. Therefore, it is optimal to incorporate the core dump function into the boot program.
[0011]
FIG. 1 is a block diagram showing the configuration of the computer system according to this embodiment. In the figure, a CPU (central processing unit) 10 performs overall control of the operation of each unit in the system by executing various programs stored in a
[0012]
The
[0013]
In addition, the
[0014]
Next, a ROM (Read Only Memory) 30 stores a boot program 31 for booting the system and a
[0015]
Next, a RAM (Random Access Memory) 40 stores a system program 21 and an
Next, the PUI (panel user interface) 50 is an interface circuit that receives the operation content when the user operates the front panel 51 from the front panel 51 and transmits it to the
[0016]
The RTC (real time clock) 60 is a calendar integrated circuit that operates under the control of the
Next, the
[0017]
By the way, as described above, a core dump request can occur in various system states, but in the present embodiment, a core dump request is made in response to an event described below.
[Timing (1)] Reboot request with core dump by program
When the system program 21 or the
[0018]
[Timing (2)] Reset instruction from the front panel
When the user recognizes that the operation of the system is abnormal, the user presses a reset button installed on the front panel 51 and instructs the system to perform a hardware reset. As described above, since the PUI 50 generates an NMI signal when the reset button is pressed, this NMI signal triggers a core dump request to the system program 21 responsible for interrupt processing.
[0019]
[Timing (3)] Instruction for resetting twice from the debug board
As described above, the
[0020]
[Timing ▲ 4 ▼] Jump to address “0”
As long as the application and the OS are programmed correctly, it is not normally possible for the program to jump to the address “0”. However, if there is a bug in the application or the like, a situation may occur in which a jump to address “0” occurs. For example, when a function call is made, the start address of the called function is specified as a pointer. In that case, if there is a bug in the program and the correct value is not set in the pointer, “0” set by default is set in the pointer, and as a result, the address “0” (that is, the start address of the boot program 31). Jump to). For this reason, when the boot program 31 detects that it has been started by a jump from the address “0”, it makes this a core dump request.
[0021]
Next, an implementation means for performing a core dump after reboot will be described.
[Realization means (1)]
This realization means presupposes at least a state in which the OS is operating normally, and corresponds to the above-described opportunity (1). The implementation means refers to the
[0022]
[Realization means (2)]
This implementation means is an implementation means used when it is necessary to reboot after going through a hardware reset, such as when it is hung up or when the OS is running out of control. That is, the realization means (2) is for the above-mentioned opportunity (2) and opportunity (3) (although it can also be used in the case of opportunity (1)). As described above, when a hardware reset is performed, there is a risk that the reset operation and the instruction execution operation overlap and the
[0023]
For this reason, the realization means (2) uses the general-purpose register 61 provided in the
[0024]
In the actual operation process, the boot program 31 always checks both the
[0025]
[Realization means (3)]
This realization means is used when the boot program 31 is started as a result of jumping to the address “0”, and is an implementation means corresponding to the above-mentioned opportunity (4). In the realization means (3), the boot program 31 refers to the jump destination address held in the stack 11, and if the content is “0”, it is regarded as a jump from the address “0”, and the
[0026]
Next, a core dump process performed in the computer system having the above configuration will be described. In the following description, it is assumed that the system program 21 and the
[0027]
First, the case where the above-described opportunity (1) occurs will be described. When the
[0028]
After the core dump process, the boot program 31 clears the
[0029]
Next, a case where the above-described opportunity (2) occurs will be described. When the user notices that there is no response even when the user gives an instruction to the system from the front panel 51 because the system hangs up, the user presses the reset button on the front panel 51. As a result, the PUI 50 sends an NMI signal to the
[0030]
Next, a case where the above-described opportunity (3) occurs will be described. When the
[0031]
Next, the case where the above-described opportunity (4) occurs will be described. It is assumed that there is a bug in the
[0032]
As described above, the core dump function is integrated into the
[0033]
Further, as described above, the trigger of the core dump is not always found when the application program is executed. In other words, the trigger (2) and the trigger (3) are generated asynchronously with the running of the application program. Therefore, the application cannot grasp these triggers and can be detected for the first time when the boot program 31 is executed. Further, the opportunity (4) can be understood only when the boot program 31 is started by jumping to the address “0”. Therefore, in this embodiment, the presence of a core dump request is left in the
[0034]
【The invention's effect】
As described above, in the present invention, the request data indicating the core dump request is set at the time when the event indicating the occurrence of the abnormality is detected, and the reboot process that is started when the abnormality occurs is completed. The request data is examined, and if a core dump is requested, a core dump is performed. As a result, since the core dump is performed in a state where the system is normally booted up by the reboot process, the core dump process can be reliably performed even in a critical situation where even the OS runs away. In addition, since a core dump request generated in various states of the system is once set as request data and the core dump request is determined at the time of rebooting, the core dump function can be centrally managed by a boot program or the like.
[0035]
Further, in the invention described in
Further, in the invention described in
[0036]
According to another aspect of the present invention, a jump destination address when a jump occurs in the program is stored, and a core dump request is set when the jump destination address is an address that the program should not run. I am doing so. As a result, a core dump can be performed by capturing an event such as a jump to the address “0” that often occurs due to a bug in the program.
According to the fifth aspect of the present invention, a core dump is performed in a fixed area on the external storage device, and the contents of the main memory written in the fixed area are stored in the storage area on the external storage device. As a result, when an abnormal state occurs repeatedly, the collected core dumps can be comprehensively used for investigating the cause.
In the invention described in claim 6, the function of the storage means is incorporated into the application program, and the collected core dump is compressed and stored. As a result, it is possible to reduce the storage area required to accumulate the core dump while addressing the problem that it is difficult to incorporate the compression process into the boot program.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a computer system according to an embodiment of the present invention.
FIG. 2 is an explanatory diagram showing area allocation on the
[Explanation of symbols]
10 ... CPU, 11 ... stack, 20 ... HDD, 21 ... system program, 22 ... application program, 23 ... fixed area, 24 ... storage area, 30 ... ROM, 31 ... boot program, 32 ... Core dump program, 40 ... RAM, 41 ... Flag, 50 ... PUI, 51 ... Front panel, 60 ... RTC, 61 ... General-purpose register, 70 ... Debug board.
Claims (4)
前記コアダンプの要求の有無を表す要求データを保持するための、前記主記憶上の所定位置に設けられたフラグと、システムのハードウェアリセットによって保持内容が影響を受けない不揮発性媒体とを有する保持手段と、
前記異常の発生を示す事象を検出した時点で、前記異常の種類に応じて、前記コアダンプの要求を示す要求データを前記フラグ及び前記不揮発性媒体のいずれか一方に設定する設定手段と、
前記異常の発生に伴って起動されるシステムのリブート処理が完了してから、前記フラグに設定されている前記要求データの内容と前記不揮発性媒体に設定されている前記要求データの内容とを調べ、2つの該要求データのいずれか一方が前記コアダンプの要求を示していることを条件として前記コアダンプを行うコアダンプ手段と
を具備することを特徴とするコンピュータシステム。In a computer system that performs a core dump that writes the contents of the main memory of the system to an external storage device when an abnormality occurs in the system,
Holding having a flag provided at a predetermined position on the main memory for holding request data indicating the presence or absence of the core dump request and a non-volatile medium whose holding contents are not affected by a hardware reset of the system Means,
Setting means for setting request data indicating a request for the core dump in either the flag or the non-volatile medium at the time of detecting an event indicating the occurrence of the abnormality, according to the type of the abnormality ,
After the reboot process of the system to be activated with the occurrence of abnormality is completed, examine the contents of the requested data set in the content and the nonvolatile media of the requested data set in the flag And a core dump means for performing the core dump on condition that either one of the two request data indicates a request for the core dump.
前記設定手段は、前記ジャンプ先アドレスが前記プログラムの走行するはずのないアドレスであることを検出して、前記要求データを前記保持手段に設定することを特徴とする請求項1記載のコンピュータシステム。Storage means for storing a jump destination address when a jump occurs in a program running on the system;
2. The computer system according to claim 1, wherein the setting unit detects that the jump destination address is an address that the program should not run and sets the request data in the holding unit.
該固定領域に書き出された前記主記憶の内容を前記外部記憶装置上の蓄積領域に蓄積してゆく蓄積手段をさらに有することを特徴とする請求項1又は2記載のコンピュータシステム。The core dump means writes the contents of the main memory to a fixed area on the external storage device,
3. The computer system according to claim 1, further comprising storage means for storing the contents of the main memory written in the fixed area in a storage area on the external storage device.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP27032498A JP4269362B2 (en) | 1998-09-24 | 1998-09-24 | Computer system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP27032498A JP4269362B2 (en) | 1998-09-24 | 1998-09-24 | Computer system |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2000099372A JP2000099372A (en) | 2000-04-07 |
JP4269362B2 true JP4269362B2 (en) | 2009-05-27 |
Family
ID=17484688
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP27032498A Expired - Fee Related JP4269362B2 (en) | 1998-09-24 | 1998-09-24 | Computer system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4269362B2 (en) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4677214B2 (en) * | 2004-09-06 | 2011-04-27 | 富士通株式会社 | Program, method and mechanism for collecting panic dump |
JP2007087263A (en) * | 2005-09-26 | 2007-04-05 | Nec Corp | Dump method in computer system having mirror memory configuration, dump control mechanism, and dump program |
JP2007094537A (en) * | 2005-09-27 | 2007-04-12 | Hitachi Ltd | Memory dump device and memory dump collection method |
JP2011181093A (en) * | 2011-05-09 | 2011-09-15 | Nec Corp | Dump method in computer system of mirror memory constitution, dump control mechanism, and program |
WO2019183829A1 (en) * | 2018-03-28 | 2019-10-03 | 深圳市大疆创新科技有限公司 | Method and device for applying system chip internal storage medium space, and unmanned aerial vehicle |
JP7283108B2 (en) * | 2019-02-15 | 2023-05-30 | 株式会社リコー | Information processing device, control method, and program |
CN110427233A (en) * | 2019-06-26 | 2019-11-08 | 北京三快在线科技有限公司 | Back-end data binding method, device, electronic equipment and storage medium |
-
1998
- 1998-09-24 JP JP27032498A patent/JP4269362B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2000099372A (en) | 2000-04-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5948112A (en) | Method and apparatus for recovering from software faults | |
US7716520B2 (en) | Multi-CPU computer and method of restarting system | |
US6516429B1 (en) | Method and apparatus for run-time deconfiguration of a processor in a symmetrical multi-processing system | |
US6502208B1 (en) | Method and system for check stop error handling | |
EP0505706B1 (en) | Alternate processor continuation of the task of a failed processor | |
US7774636B2 (en) | Method and system for kernel panic recovery | |
US6959262B2 (en) | Diagnostic monitor for use with an operating system and methods therefor | |
WO2001040946A1 (en) | Automated recovery of computer appliances | |
JP2004259258A (en) | Improved diagnostic execution apparatus and its method | |
US20120042215A1 (en) | Request processing system provided with multi-core processor | |
JP3481737B2 (en) | Dump collection device and dump collection method | |
US7631224B2 (en) | Program, method, and mechanism for taking panic dump | |
TWI441081B (en) | Method for flashing firmware and booting method and electronic apparatus using the method thereof | |
JP5609242B2 (en) | Information processing apparatus and memory dump collection method | |
JP4269362B2 (en) | Computer system | |
US7430683B2 (en) | Method and apparatus for enabling run-time recovery of a failed platform | |
US8069309B1 (en) | Servicing memory in response to system failure | |
CA2340342A1 (en) | A method, computer, and article of manufacturing for fault tolerant booting | |
WO2000054133A1 (en) | Information processor, method for saving/loading data, and information recorded medium | |
JPH02294739A (en) | Fault detecting system | |
CN112650610B (en) | Linux system crash control method, system and medium | |
Kudrjavets et al. | When malloc () Never Returns NULL—Reliability as an Illusion | |
US8042176B2 (en) | Computer readable medium on which is stored a program for preventing the unauthorized use of program data | |
EP2360591A1 (en) | Volatile memory content capturing method and processing system | |
JP7074291B2 (en) | Information processing equipment, information processing methods and programs |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041224 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071025 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071127 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080128 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080729 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080929 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090203 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090216 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120306 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130306 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140306 Year of fee payment: 5 |
|
LAPS | Cancellation because of no payment of annual fees |