JP2018036799A - 情報処理装置およびその制御方法 - Google Patents

Abstract

【課題】情報処理装置の起動時間に影響を与えることなくヒープダンプファイルを生成する情報処理装置及びその制御方法を提供する。
【解決手段】メモリ制御部はＥｒｒｏｒを発生したかを確認し、発生した場合はヒープダンプ生成部にヒープダンプ生成要求を送信する。ヒープダンプ生成部は指定された生成パスのヒープダンプファイルを確認し、存在しないと判定した場合は、指定されたファイル名のヒープダンプファイルを生成する。いったん生成されたヒープダンプファイルは、次回の電源投入後の初期化処理で削除されるまで存続する。回収ファイル生成部は、回収ファイルの編集処理後、ヒープダンプファイルを元に回収ファイルの生成処理を行い、ファイルサイズ変更部にサイズ変更要求を行う。ファイルサイズ変更後は画像形成装置のシャットダウンが行われるまでＥｒｒｏｒ発生待ちに戻る。
【選択図】図４

Description

本発明は、情報処理装置で作成したログファイル（ヒープダンプファイル）を制御する技術に関する。

従来、情報処理装置上で動作するアプリケーション（アプリ）の実行環境としてＪａｖａ（登録商標、以下省略）が広く知られている。この実行環境では、Ｊａｖａ言語で記述されたアプリ（ＪａｖａアプリあるいはＪａｖａアプリケーション）が、Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＪａｖａＶＭ）上で動作する。Ｊａｖａアプリはメモリを利用する場合、ＪａｖａＶＭにメモリ要求を行う。ＪａｖａＶＭは、あらかじめ情報処理装置のメモリ領域からＪａｖａアプリが利用可能なメモリ領域（Ｊａｖａヒープ領域）として固定の領域を確保しており、Ｊａｖａアプリからのメモリ要求を受信すると、このＪａｖａヒープ領域に空きがあるかを確認する。そして空きがある場合、ＪａｖａＶＭはＪａｖａアプリからの要求に応じたメモリ領域をＪａｖａアプリが利用可能にする。一方、Ｊａｖａヒープ領域に空きがない場合は、ＪａｖａＶＭはＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒというエラーを発生する。ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生した場合、原因を特定するためにＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時に生成したヒープダンプファイルというログファイルを解析する。このヒープダンプファイルは、Ｊａｖａヒープ領域内のメモリ利用状態を表したファイルである。

Ｊａｖａ実行環境において、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時にヒープダンプファイルを生成する方法として、ＪａｖａＶＭの起動オプションを利用する方法がある。このＪａｖａＶＭの起動オプションは、「ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時に、決められたファイルパスにヒープダンプファイルを生成する」というものである。なおこのオプションでは、上記で指定したファイルパスに既にファイルが存在する場合は、ファイルを新規で生成しない。そのため、初回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時にヒープダンプファイルを１つ生成するものである。なお、情報処理装置で一度ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生すると、それ以降にメモリ要求を行っても常にＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生してしまう。このため、初回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時のヒープダンプファイルを解析するのが一般的である。

一方、画像形成装置のような情報処理装置では、それが置かれている現場からヒープダンプファイルを回収するのは時間や手間がかかる。そのため、現場で発生したＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒをより早く、より正確に原因調査を行うために、複数のヒープダンプファイルを取得したいという要望がある。しかし、画像形成装置のようにハード的な記憶容量が制限された情報処理装置では、生成した全てのログファイルを記憶することができないという課題がある。このための解決手段として、特許文献１のように、ログファイルのローテーションと取得の両方の処理を排他制御してログファイルの整合性を保ちつつ、最新のログファイルを所定数だけ残す技術が知られている。

特開２００９−２２３０４号公報

現場での早期問題解決のため、複数のヒープダンプファイルを取得したいという要望があるが、ＪａｖａＶＭの起動オプションでは複数のヒープダンプファイルを残すことができない。なお、情報処理装置の起動時の初期化処理において、既にヒープダンプファイルが存在していた場合は、存在するファイルをリネームして保存し、元のヒープダンプファイルを消去することで、従来の技術のように、最新のヒープダンプファイルを複数生成することも考えられる。

しかし、ＣＰＵの数や性能など、リソースに制限がある画像形成装置のような情報処理装置では、初期化時に複数の処理が並行して動作するため、ＣＰＵの稼働率が高い状態になっている。このような状態の初期化処理において、ファイルサイズの大きいファイルを削除すると、完了するまでに長い時間が必要になり、情報処理装置全体の起動時間に大きな影響を与えてしまう。そのため、従来の技術を利用した方法では、情報処理装置の起動時間に影響を与えてしまい、ユーザの操作性が低下するという課題があった。

本発明は上記従来例に鑑みて成されたもので、起動時間に与える影響を抑制しつつ、新しい所定数のヒープダンプファイルを残す情報処理装置及びその制御方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

エラーの発生をトリガとして、ログファイルが無い場合にはログファイルを生成するログファイル生成手段と、
前記ログファイル生成部で生成した前記ログファイルを別名のファイルとして保存する別名ファイル生成手段と、
前記ログファイルのファイルサイズを縮小するファイルサイズ変更手段と、
前記ファイルサイズ変更手段により前記ファイルサイズを変更した前記ログファイルを、所定のタイミングで削除するファイル削除手段とを有することを特徴とする情報処理装置。

本発明により、起動時間に与える影響を抑制しつつ、新しい所定数のヒープダンプファイルを残すことができる。

本発明の各実施形態に共通する画像形成装置１００のコントローラユニット１１１を表すブロック図である。 本発明の各実施形態に共通するコントローラユニット１１１のソフトウエア構成を表すブロック図である。 本発明の各実施形態に共通する図２のＪａｖａＶＭ２０２とアプリプラットフォーム２０３のモジュール構成を表す図である。 本発明の各実施形態に共通するヒープダンプ生成処理を表すフローチャート図である。 本発明の各実施形態に共通する複数のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生するタイミングを表すイメージ図である。 本発明の各実施形態に共通するファイル送信処理を表すフローチャート図である。 本発明の第２実施形態のヒープダンプ生成処理を表すフローチャート図である。

以下、本発明を実施するための最良の形態について、図面を用いて説明する。

［第１の実施形態］
最初に、情報処理装置の一実施例である画像形成装置のコントローラユニットの説明を行う。

●画像形成装置のコントローラユニットの構成
図１は、本発明の各実施形態に係る画像形成装置１００のコントローラユニットの内部構造を示すブロック図である。画像形成装置１００は例えば複合機（ＭＦＰ）であり、情報処理の観点からは情報処理装置ということもできる。コントローラユニット１１１は、ログファイルやデバイス情報の入出力を行うだけではなく、画像形成装置１００全体の制御や、ネットワークを介して外部へのデータ送信の制御も行う。コントローラユニット１１１は、各種制御プログラムを実行するＣＰＵ１０１を有する。

ＣＰＵ１０１は、ＲＯＭ１０３に記憶されているブートプログラムに基づきシステムを起動し、このシステム上でＨＤＤ（ハードディスク装置）１０４に記憶されている制御プログラムを読み出してＲＡＭ１０２をワークエリアとして所定の処理を実行する。この制御プログラムにより、Ｊａｖａプログラムなどの所定の制御を実行することが可能である。また実行される処理には、例えば図２、図３に示すソフトウェアモジュールを実現する処理や、図４、図６、図７に示す手順の処理を含む。ＨＤＤ１０４には、上記各種制御プログラムが記憶されるとともに、ログデータに関する全ての設定や後述するネットワーク部１０７が有するすべての通信手段に関する情報を記憶する。

ＣＰＵ１０１には、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４がシステムバス１１０を介して接続されている。さらに操作部Ｉ／Ｆ１０５、ネットワーク部１０７、電源管理部１０９がシステムバス１１０を介して接続されている。

操作部Ｉ／Ｆ１０５は、操作部１０６との間のインターフェイス部であり、操作部１０６に表示する画像データの操作部１０６への転送、操作部１０６における操作入力により発生した信号のＣＰＵ１０１への転送などを行う。操作部１０６は、画像処理に関する各機能における現在の設定状態、各機能に関する設定情報を入力するための情報入力画面などを表示するための表示部、ユーザが各機能に対する設定情報を入力するキーなどを含む入力部を有する。

電源管理部１０９は、画像形成装置１００の電源ＯＦＦと電源ＯＮの管理を行う。なおＣＰＵ１０１は、電源ＯＮや電源ＯＦＦを検知した場合、上述のように、ＲＯＭ１０３のブートプログラムやＨＤＤ１０４に記憶されている制御プログラムを実行する。これにより、画像形成装置１００の初期化処理やシャットダウン処理を実行する。

ネットワーク部１０７は、ＬＡＮ１０８に接続され、ＬＡＮ１０８を介した情報の入出力を行う。ＬＡＮ回線にｗｅｂサーバや外部装置が接続されている場合は、そのサーバからＬＡＮ１０８を介して情報を出力することが可能である。また、ＬＡＮ回線内のプロキシサーバなどを介して、インターネットに接続し、インターネット上のｗｅｂサーバにファイルを送信することも可能である。

●ソフトウェアモジュールの構成
次に、図２を用いて画像形成装置１００のＣＰＵ１０１やＨＤＤ１０４などの各ハードウエア上で動作するソフトウエアのモジュール構成を説明する。なおこれらの各モジュールにおける処理は、ＣＰＵ１０１の命令により、ＲＯＭ１０３やＨＤＤ１０４に記憶されているプログラムを読み出し、ＲＡＭ１０２をワークエリアとして所定の処理を実行することで実現している。また、所定の処理を実行することで生成される全ての情報は、ＲＡＭ１０２もしくはＨＤＤ１０４に記憶する。なお、このような各モジュールにおける処理は、以降でも同様であるため、以降では記載を省略する。

ＯＳ２０１は、画像形成装置１００全体のプロセス管理、メモリ管理、入出力管理等を行うモジュールであり、一般的なＯＳと同様の処理を行う。

ＪａｖａＶＭ２０２は、ＨＤＤ１０４に記憶されているＪａｖａバイトコードを実行することでＪａｖａプログラムを動作させる仮想マシンである。このＪａｖａＶＭ２０２は、画像形成装置１００の起動時の初期処理で起動するが、起動の際に起動オプションを指定して起動することができる。この起動オプションとしては、ヒープダンプファイルの生成有無の指定や、ヒープダンプファイルを生成する場所（生成パス）の指定、生成するヒープダンプファイルのファイル名の指定などがあり、これらの値はＨＤＤ１０４にあらかじめ記憶していることとする。なお本実施形態では、ＪａｖａＶＭ２０２の起動オプションで、ヒープダンプファイルの生成を有効に指定し、ヒープダンプファイルの生成パスと生成するファイル名も特定のものを指定していることとする。

アプリプラットフォーム２０３は、単一のＪａｖａＶＭ２０２上で少なくとも１つ以上のＪａｖａアプリ（あるいはＪａｖａアプリケーション）の起動、停止、インストール、アンインストールといったアプリのライフサイクルの管理・実行を行うモジュールである。また、アプリプラットフォーム２０３は、後述のアプリＡ２０４やアプリＢ２０５で共通に利用するライブラリやサービスを有する。なおアプリとは、アプリケーションプログラムの略称であり、本実施形態では「アプリ」を用いる。

アプリＡ２０４とアプリＢ２０５は、アプリプラットフォーム２０３上で動作するＪａｖａプログラムのバイトコードであり、アプリプラットフォーム２０３が有するライブラリやサービスを利用して動作する。また、アプリＡ２０４とアプリＢ２０５は、個々のアプリ毎に画像形成装置１００にインストールして、アプリプラットフォーム２０３で動作することが可能である。

アプリＣ２０６は、Ｊａｖａアプリ以外のアプリ（例えばＣ言語のアプリ）のプログラムのバイトコードであり、ＯＳ２０１上で動作する。

●ＪａｖａＶＭおよびアプリプラットフォーム
ここで、ＪａｖａＶＭ２０２とアプリプラットフォーム２０３の詳細な説明を、図３のモジュール構成図を用いて行う。ＪａｖａＶＭ２０２は、メモリ制御部３０１とヒープダンプ生成部３０２からなる。アプリプラットフォーム２０３は、回収ファイル生成部３０３、ファイルサイズ変更部３０４、ファイル削除部３０５、ファイル送信部３０６、エラー検知部３０７からなる。

メモリ制御部３０１は、Ｊａｖａアプリのどのオブジェクトがどれくらいのメモリを利用しているのかをＨＤＤ１０４に記憶する。また、メモリ制御部３０１は、Ｊａｖａアプリからのメモリ利用要求を受信すると、Ｊａｖａヒープメモリ領域（以下、メモリ領域）の利用状況を調べる。そしてメモリ制御部３０１は、要求されたサイズのメモリ領域が確保できればＪａｖａアプリに確保したメモリ領域を返し、メモリ領域を確保できなければ、ヒープダンプ生成部３０２にヒープダンプファイルの生成要求を行う。

ヒープダンプ生成部３０２は、この生成要求を受信すると、ＪａｖａＶＭ２０２の起動オプションでヒープダンプファイルの生成が有効になっているかを調べる。そして、有効になっている場合は、ヒープダンプ生成部３０２は、ＨＤＤ１０４に記憶しているメモリ利用状況を元に、ヒープダンプファイルの生成を行う。なお、生成するヒープダンプファイルの生成パスとファイル名は、ＪａｖａＶＭ２０２に起動オプションであらかじめＨＤＤ１０４に記憶されているため、この生成パスに決められたファイル名のヒープダンプファイルを生成する。ヒープダンプファイルはログファイルともいえるので、ヒープダンプ生成部３０２はまた、ログファイル生成部ということもできる。また、ヒープダンプ生成部３０２は、回収ファイル生成部３０３に回収ファイル生成要求を行う。

回収ファイル生成部３０３は、ヒープダンプ生成部３０２からの回収ファイル生成要求を受信すると、既に存在する回収用ファイルの数と回収用ファイルの最大数とに応じて回収用ファイルの削除を行う。回収用ファイルとは、ヒープダンプファイルの名称を変更した別名ファイルであり、望ましくは名称にファイルの新旧を示す情報を含み、さらに望ましくは圧縮されている。さらに回収ファイル生成部３０３は、ヒープダンプ生成部３０２で生成したヒープダンプファイルを元にして、回収用ファイルを作成する。回収ファイル生成部３０３は、ヒープダンプファイルの名称を変更して別途保存するため、たとえば別名ファイル生成手段などということもできる。また、回収ファイル生成部３０３は、回収用ファイル生成後に、ヒープダンプファイルのファイルサイズ変更要求をファイルサイズ変更部３０４に送信する。

ファイルサイズ変更部３０４は、回収ファイル生成部３０３からのファイルサイズ変更要求を受信すると、ヒープダンプ生成部３０２で生成したヒープダンプファイルのファイルサイズを変更する。

ファイル削除部３０５は、画像形成装置１００の初期化処理におけるアプリプラットフォーム２０３の初期化処理において、ファイルサイズ変更部３０４でファイルサイズを変更したヒープダンプファイルを削除する。

ファイル送信部３０６は、回収ファイル生成部３０３で生成した回収用ファイルを、ネットワーク部１０７により画像形成装置１００の外部に送信する。

エラー検知部３０７は、画像形成装置１００が異常状態となるシステムエラー（操作部１０６の応答なしエラーやＲＡＭ１０２のアクセスエラーなど）を検知し、あらかじめＨＤＤ１０４に記憶されている所定の制御を行う。
以上が、ＪａｖａＶＭ２０２とアプリプラットフォーム２０３の詳細な説明である。

●ヒープダンプファイルの生成処理
続いて、ＪａｖａＶＭ２０２とアプリプラットフォーム２０３の各モジュールにより、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ（すなわちメモリ不足エラー）が発生した場合に、ヒープダンプファイルを生成する処理の説明を、フローチャート図４を用いて説明する。なおこのフローチャート図４を用いた具体例は、フローチャートの処理の説明後に行う。図４の処理はハードウエア上はＣＰＵ１０１がプログラムを実行することで実現されるが、以下では、図３に示す各モジュールが、処理の主体となるオブジェクトであるとして説明する。

画像形成装置１００を起動すると、電源管理部１０９は、あらかじめＨＤＤ１０４に記憶しているプログラムに従って初期化処理（ＪａｖａＶＭ２０２の起動やアプリプラットフォーム２０３の初期化処理など）を実行する。この初期化処理の一処理であるアプリプラットフォーム２０３の初期化処理を説明する。ファイル削除部３０５は、ＪａｖａＶＭ２０２の起動オプションで指定されているヒープダンプファイルの生成パスに、起動オプションで指定されているファイル名のヒープダンプファイルが存在するかを判定する（ステップ４０１）。ここでヒープダンプファイルが存在すると判定した場合は、ファイル削除部３０５は、このヒープダンプファイルを削除する（ステップ４０２）。一方、ヒープダンプファイルが存在しないと判定した場合は、ファイル削除部３０５は何もしない。

この後、画像形成装置１００の電源管理部１０９によりシャットダウンが検知されるまでステップ４０３〜４１１を繰り返す。この処理を説明する。

メモリ制御部３０１は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生したか確認する（ステップ４０３）。ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒは前述したように、たとえばアプリからのメモリアロケーションの要求に対して、メモリ制御部３０１が、割り当てる空きメモリをヒープ領域に確保できないと判定した場合に発生する。ここでＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生していない場合は、一般的なメモリ管理処理（詳細は省略）を行う。一方、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生した場合は、メモリ制御部３０１は、ヒープダンプ生成部３０２にヒープダンプ生成要求を送信する。

ヒープダンプ生成要求を受信したヒープダンプ生成部３０２は、ＪａｖａＶＭ２０２の起動オプションで指定されたヒープダンプファイルの生成パスのヒープダンプファイルを確認する（ステップ４０４）。すなわち、ヒープダンプファイルの有無を判定する。ここで、生成パスにヒープダンプファイルが存在すると判定した場合は、ステップ４０３の待ちに戻る。一方、生成パスにヒープダンプファイルが存在しないと判定した場合は、ヒープダンプ生成部３０２は、ＪａｖａＶＭ２０２の起動オプションで指定された生成パスに、指定されたファイル名のヒープダンプファイルを生成する（ステップ４０５）。生成されたヒープダンプファイルには、メモリ領域（たとえばＪａｖａヒープメモリ領域）の利用状況を示す情報が含まれている。いったん生成されたヒープダンプファイルは、次回の電源投入後の初期化処理（Ｓ４０２）で削除されるまで存続する。つまり、画像形成装置１００が起動してからシャットダウンするまでの間で、ヒープダンプ生成部３０２は、初回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生したときのみヒープダンプファイルを生成することになる。なお、ヒープダンプ生成部３０２におけるヒープダンプファイル生成処理は、一般的なヒープダンプ生成処理と同じであるため、詳細は省略する。

ヒープダンプ生成部３０２は、ヒープダンプファイル生成後に、回収ファイル生成部３０３に回収ファイル生成要求を送信する。この回収ファイル生成要求を受信した回収ファイル生成部３０３は、あらかじめＨＤＤ１０４に記憶している回収用ファイルの生成パスに、既に回収用ファイルが存在するか判定する（ステップ４０６）。なおこの回収用ファイルの詳細は、ステップ４０８で後述する。ここで回収ファイルが存在すると判定した場合は、回収ファイル生成部３０３は回収用ファイルの編集を行う（ステップ４０７）。この回収用ファイルの編集処理について説明する。回収用ファイルはＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの解析に必要なファイルであるが、画像形成装置１００のＨＤＤ１０４の容量は小さいため、残すことができる回収用ファイル数も限られている。そのため、最大の回収用ファイル数を所定の値にあらかじめ決めておき、最大回収用ファイル数を越えないように、新しく生成した回収ファイルを残すことが必要である。そのため、ステップ４０７で回収ファイル生成部３０３は、あらかじめ決められた最大回収用ファイル数よりも１つ少ないファイル数にするための編集処理を行う（後述のステップ４０８で回収用ファイルを１つ生成するため）。具体的な編集処理としては、回収用ファイルのファイル名には作成日時を含めるため（後述のステップ４０８で説明あり）、回収用ファイル名を確認し、作成日時が最も古いファイルを削除する処理を行う。以上が回収用ファイルの編集処理の説明である。一方、ステップ４０６で回収ファイルが存在しないと判定した場合は、ステップ４０８へと分岐する。

回収ファイル生成部３０３は、回収用ファイルの編集処理後、さらにヒープダンプ生成部３０２で生成したヒープダンプファイルを元に、回収用ファイルの生成処理を行う（ステップ４０８）。この回収用ファイルの生成処理について説明する。回収ファイル生成部３０３は、ステップ４０５で生成したヒープダンプファイルの生成日時の情報を取得する。そして回収ファイル生成部３０３は、このヒープダンプファイルをコピーして別のファイルを生成し、このファイルのファイル名称に、取得したヒープダンプファイルの生成日時を追加する。このようにして作成したのが回収用ファイルである。なおこの回収用ファイルは、ＨＤＤ１０４のあらかじめ決められた場所（生成パス）に記憶する。なお本実施形態では、ＨＤＤ１０４の使用量を抑えるために、回収用ファイルは圧縮して生成したが、ファイルを解凍することなく解析できるようにするため、回収用ファイルは圧縮しなくてもよい。また本実施形態では、古い回収用ファイルと新しい回収用ファイルを判断するために、回収用ファイルに生成日時情報を追加したが、別の方法により判断しても良い。例えば、日時情報ではなく、古い順に固定の数値をつけるなどの方法で、回収用ファイルの新旧を判断することもできる。以上が、回収用ファイルの生成処理である。回収ファイル生成部３０３は、回収用ファイル生成後、ファイルサイズ変更部３０４にヒープダンプファイルのファイルサイズ変更要求を送信する。

ファイルサイズ変更部３０４は、ファイルサイズ変更要求を受信すると、ステップ４０５で生成したヒープダンプファイルのサイズを変更する（ステップ４０９）。ここでファイルサイズ変更を行うのは、ステップ４０１の初期化時のヒープダンプファイル削除の処理時間を減らすためである。ファイルの削除処理にかかる時間は、ファイルサイズが小さいほど短くなるため、ファイルサイズは小さい方が望ましい。本実施例では、ヒープダンプファイルを一度削除し、同じファイル名で中身が０ｂｙｔｅのファイルを生成することで、ヒープダンプファイルのサイズを０ｂｙｔｅにする。なおファイルサイズを０ｂｙｔｅにする方法は、ファイルをＯｐｅｎし、中身を全て消す処理を実行する方法でも良い。ファイルサイズ変更部３０４でファイルサイズ変更後は、画像形成装置１００のシャットダウンが行われるまで、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生待ち（ステップ４０３）に戻る。

以上が、フローチャート図４の説明である。このようにして、生成したヒープダンプファイルを回収用ファイルとしてアーカイブし、アーカイブ後のヒープダンプファイルサイズを０に変更しておくことで、その削除を短時間で行うことができる。さらに、ヒープダンプファイルを、その新旧を示す情報をメタデータとしてアーカイブしておくことで実質的に複数のヒープダンプファイルを保存しておくことができる。

なお、図４のステップ４０３とステップ４０４とで形成されるループ、および、ステップ４０３からステップ４０９までのステップで形成されるループはいずれも説明のための構成であると考えてもよい。たとえばステップ４０４においてヒープダンプファイルがあると判定した場合、および、ステップ４０９でヒープダンプファイルのサイズを０に変更する処理を終えた場合には、いったんエンドタスクする。そして、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生をトリガとしてステップ４０３（あるいはステップ４０４）から処理を再開するように構成してもよい。エンドタスクの後は、空いたＣＰＵなどの計算資源により他の処理を実行できる。

●ヒープダンプファイル生成処理の具体例
続いて、このフローチャート図４の具体例を、図５のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生イメージ図を用いて説明する。まず図５の簡単な説明を行う。図５の横軸は時間であり、図５の符号５０１から符号５１４は画像形成装置１００で行われる処理やイベントを表している。電源ＯＮ５０１、５０７、５１２は、画像形成装置１００の電源をＯＮにしたことを電源管理部１０９で検知したことを表すイベントであり、この後に画像形成装置１００の初期化処理５０２、５０８、５１３を行う。電源ＯＦＦ５０６、５１１は、画像形成装置１００をシャットダウンして電源がＯＦＦになったことを電源管理部１０９で検知したことを表すイベントである。ＯＯＭＥ５０３〜５０５、ＯＯＭＥ５０９〜５１０、ＯＯＭＥ５１４は、画像形成装置１００で発生したＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを表す。すなわち図５は、画像形成装置１００が最初に起動してからシャットダウンするまでに３回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ５０３，５０４，５０５が発生したことを表す。また図５は、その後に画像形成装置１００を再起動してから２回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ５０９，５１０が発生し、さらにその後に画像形成装置１００を再起動してからＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ５１４が１回発生したことを表している。なお、これらのＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒは、アプリＡ２０４やアプリＢ２０５のメモリ取得要求により発生するものであるが、どちらのアプリによるＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒでも同じＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒとして処理する。以上が図５の簡単な説明である。

なお、本実施形態では、ＪａｖａＶＭ２０２の起動オプションとして、"−ＸＸ：＋ＨｅａｐＤｕｍｐＯｎＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ"と指定することで、ヒープダンプファイルの生成を有効にしていることとする。またＪａｖａＶＭ２０２の起動オプションとして、"−ＸＸ：ＨｅａｐＤｕｍｐＰａｔｈ＝／ｒｏｏｔ／ｍｙｌｏｇ／ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"と指定することでヒープダンプファイルの生成パスと生成するヒープダンプファイル名を指定する。このときに指定する生成パスは"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリであり、生成するヒープダンプファイル名の指定は"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"である。また本実施形態では、回収ファイルの生成パスとして"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリが指定され、回収ファイル名は"ｈｅａｐｄｕｍｐ＿ＸＸＸＸ．ｇｚ"（ＸＸＸＸは可変であり、日時が入る）というファイル名称をあらかじめ決めていることとする。また本実施形態では、回収する回収ファイル数の最大数（すなわち保存される回収ファイルの数の上限）は２とあらかじめ決めていることとする。なお、これらの生成パスやファイル名や最大回収ファイル数は、全てＨＤＤ１０４に記憶していることとする。

続いて、フローチャート図４の具体例を説明する。まず最初に、画像形成装置１００の電源管理部１０９で電源ＯＮを検知することで行う初期化処理５０２について説明する。ファイル削除部３０５は、ＪａｖａＶＭ２０２の起動オプションで指定されているヒープダンプファイルの生成パスに、ＪａｖａＶＭ２０２の起動オプションで指定されているヒープダンプファイルが存在するかを判定する（ステップ４０１）。ここでは、ヒープダンプファイルの生成パスである"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のファイルが存在しないため、初期化処理を終了する（ステップ４０３の処理に進む）。

次に、ＯＯＭＥ５０３を発生したときの処理を説明する。メモリ制御部３０１は、ＯＯＭＥ５０３によるＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を確認し（ステップ４０３−「あり」）、ヒープダンプ生成部３０２にヒープダンプ生成要求を送信する。ヒープダンプ生成要求を受信したヒープダンプ生成部３０２は、ヒープダンプファイルの生成パスにヒープダンプファイルが存在するかを判定する（ステップ４０４）。ここでは、ヒープダンプファイルの生成パスである"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のファイルが存在しない。そのため、ヒープダンプ生成部３０２は、"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のヒープダンプファイルを生成する（ステップ４０５）。その後、ヒープダンプ生成部３０２は、回収ファイル生成部３０３に回収ファイル生成要求を送信する。

この回収ファイル生成要求を受信した回収ファイル生成部３０３は、既に回収用ファイルが存在するかを判定する（ステップ４０６）。ここでは、"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに回収用ファイルが存在しない。そのため、回収ファイル生成部３０３は、ステップ４０５で生成した"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のヒープダンプファイルから"ｈｅａｐｄｕｍｐ＿２０１６０６０１１２００．ｇｚ"という回収用ファイルを生成する（ステップ４０８）。なお回収用ファイルの名称に"２０１６０６０１１２００"という文字が入っているのは、ヒープダンプファイル"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"を２０１６年６月１日１２時に生成したためである。回収ファイル生成部３０３は、回収用ファイル生成後に、ファイルサイズ変更部３０４にファイルサイズ変更要求を送信する。これを受信したファイルサイズ変更部３０４は、ステップ４０５で生成したヒープダンプファイルのサイズを変更する（ステップ４０９）。ここでは、"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリの"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"を一度削除する。そして、ファイルの内容が何も記載されていない"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という同じ名称のファイルを同じディレクトリに作る。これにより、ファイルサイズを変更することとする。以上が、ＯＯＭＥ５０３を発生したときの処理である。

次に、ＯＯＭＥ５０４を発生したときの処理を説明する。メモリ制御部３０１は、ＯＯＭＥ５０４によるＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を確認すると（ステップ４０３が「あり」）、ヒープダンプ生成要求をヒープダンプ生成部３０２に送信する。これを受信したヒープダンプ生成部３０２は、ヒープダンプファイルの生成パスにヒープダンプファイルが存在するかを判定する（ステップ４０４）。ここでは、ヒープダンプファイルの生成パスである"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のファイルが存在するため、ステップ４０３のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生待ちに戻る。そのため、ＯＯＭＥ５０４の発生により、新たにヒープダンプや回収用ファイルを生成することはない。以上がＯＯＭＥ５０４を発生したときの処理である。なお、この後にＯＯＭＥ５０５を発生しても、ＯＯＭＥ５０４を発生したときと同様に、新たにヒープダンプや回収用ファイルを生成することはない。

次に、電源ＯＦＦ５０６後に電源ＯＮ５０７を検知した後に実行する初期化処理５０８について説明する。この初期化処理５０８として、ファイル削除部３０５は、所定の生成パスに所定のヒープダンプファイルが存在するかを判定する（ステップ４０１）。なおこの所定の生成パスとは、ＪａｖａＶＭ２０２の起動オプションで指定されているヒープダンプファイルの生成パスである。また、この所定のヒープダンプファイルとは、ＪａｖａＶＭ２０２の起動オプションで指定されているヒープダンプファイルである。ここでは、ヒープダンプファイルの生成パスである"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のファイルが存在するため、ファイル削除部３０５は、このファイルを削除する（ステップ４０２）。そして初期化処理を終了する（ステップ４０３の処理に進む）。

次に、ＯＯＭＥ５０９を発生したときの処理を説明する。メモリ制御部３０１は、ＯＯＭＥ５０９によるＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を確認すると（ステップ４０３−「あり」）、ヒープダンプ生成要求をヒープダンプ生成部３０２に送信する。これを受信したヒープダンプ生成部３０２は、ヒープダンプファイルの生成パスにヒープダンプファイルが存在するかを判定する（ステップ４０４）。ここでは、ヒープダンプファイルの生成パスである"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のファイルが存在しないため、ヒープダンプ生成部３０２は、ヒープダンプファイルを生成する（ステップ４０５）。ここでは、"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のヒープダンプファイルを生成する。その後、ヒープダンプ生成部３０２は、回収ファイル生成部３０３に回収ファイル生成要求を送信する。

この回収ファイル生成要求を受信した回収ファイル生成部３０３は、既に回収用ファイルが存在するかを判定する（ステップ４０６）。ここでは、"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに"ｈｅａｐｄｕｍｐ＿２０１６０６０１１２００．ｇｚ"という名称の回収用ファイルが存在する。そのため、回収ファイル生成部３０３は、"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに存在する回収用ファイルの数が、最大回収用ファイル数よりも１つ少ない数を超えているかを判定する。ここでは最大回収用ファイル数が２であり、既に存在する回収用ファイルは１つしかないため、編集処理は行わない。その後、回収ファイル生成部３０３は、ステップ４０５で生成したヒープダンプファイルから回収用ファイルを生成する（ステップ４０８）。具体的には、"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のヒープダンプファイルから"ｈｅａｐｄｕｍｐ＿２０１６０６０１２２００．ｇｚ"という回収用ファイルを"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリに生成する。なお回収用ファイルの名称に"２０１６０６０１２２００"という文字が入っているのは、ヒープダンプファイル"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"を２０１６年６月１日２２時に生成したためである。回収ファイル生成部３０３は、回収用ファイル生成後に、ファイルサイズ変更部３０４にファイルサイズ変更要求を送信する。

これを受信したファイルサイズ変更部３０４は、ステップ４０５で生成したヒープダンプファイルのサイズを変更する（ステップ４０９）。ここでは、"／ｒｏｏｔ／ｍｙｌｏｇ／"ディレクトリの"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"を一度削除する。そして、同じディレクトリにファイルの内容が何も記載されていない"ｈｅａｐｄｕｍｐ．ｈｐｒｏｆ"という名称のファイルを作る。これにより、ファイルサイズを変更することとする。以上が、ＯＯＭＥ５０９を発生したときの処理である。なお、この後にＯＯＭＥ５１０を発生したときの処理は、ＯＯＭＥ５０４やＯＯＭＥ５０５を発生したときの処理と同じであるため、省略する。これにより、回収用ファイル"ｈｅａｐｄｕｍｐ＿２０１６０６０１１２００．ｇｚ"と"ｈｅａｐｄｕｍｐ＿２０１６０６０１２２００．ｇｚ"を生成する。

最後に、電源ＯＦＦ５１１後に電源ＯＮ５１２を行い、その後にＯＯＭＥ５１４が発生したときの説明を行う。なお、初期化処理５１３（ステップ４０１、４０２）やヒープダンプファイル生成処理（ステップ４０３〜４０５）の処理は、前述の処理と同じであるため、説明は省略する。ここでは、ステップ４０５により、回収用ファイル"ｈｅａｐｄｕｍｐ＿２０１６０６１３１２００．ｇｚ"を生成したこととする。

ステップ４０６において、回収ファイル生成部３０３は、既に回収用ファイルが存在するかを判定する。ここでは、回収用ファイル"ｈｅａｐｄｕｍｐ＿２０１６０６０１１２００．ｇｚ"と"ｈｅａｐｄｕｍｐ＿２０１６０６０１２２００．ｇｚ"の２つの回収用ファイルが存在する。そのため、回収ファイル生成部３０３は、最大回収用ファイル数の２を越えていると判定し、古いほうの回収用ファイルである"ｈｅａｐｄｕｍｐ＿２０１６０６０１１２００．ｇｚ"を削除するという編集処理を行う（ステップ４０７）。なお、この後のステップ４０８とステップ４０９の処理は、回収用ファイルのファイル名称が異なる以外は既に説明した処理と同じ処理であるため、説明は省略する。ここでは、ステップ４０８により、回収用ファイルとして"ｈｅａｐｄｕｍｐ＿２０１６０６０１２２００．ｇｚ"と"ｈｅａｐｄｕｍｐ＿２０１６０６１３１２００．ｇｚ"の２つが残ることとなる。以上がＯＯＭＥ５１４が発生したときの処理である。以上が、フローチャート図４の具体例の説明である。

これにより、ヒープダンプファイルのサイズを、初期化処理の時点では小さく（本例では０に）しておくことで、画像形成装置１００の初期化処理のファイル削除にかかる時間を短くすることができる。さらに、ヒープダンプファイルを、回収用ファイルに名前を変えて残すことができる。そのため、画像形成装置１００の起動時間に影響を与えることなく、最新のヒープダンプファイルを所定数だけ残すことができる。そのため、所定数のヒープダンプファイルを生成する場合でも、ユーザの画像形成装置１００の起動待ち時間が増えることはない。

●回収用ファイルの送信処理
最後に、上記で生成した回収用ファイルを送信するときの処理について説明する。ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの原因解析は、ユーザ（サービスマンやアプリ開発者）が回収用ファイルの内容を分析することで、特定できることがある。ファイルの分析を行う場合、回収用ファイルを画像生成装置１００の外部のＰＣに送信し、外部のＰＣでファイルの中身を分析するのが一般的である。回収用ファイルを外部に送信するための処理（回収用ファイル送信処理）を、フローチャート図６を用いて説明する。この処理は、ハードウエアの上ではＣＰＵ１０１により、オブジェクトの上ではファイル送信部３０６により実行される。

ユーザが操作部１０６で回収用ファイルを外部に送信するための入力を行うと、この入力をファイル送信部３０６は送信指示として受信する（ステップ６０１）。入力は例えば操作部１０６から行われる。

送信指示を受信したファイル送信部３０６は、あらかじめ決められた生成パスに回収用ファイルが存在するかを判定する（ステップ６０２）。具体的には、図４のステップ４０７とステップ４０８で回収用ファイルを生成した生成パス（ディレクトリ）に、回収用ファイルが存在するかを判定する。

回収用ファイルが存在する場合、ファイル送信部３０６は、存在する全ての回収用ファイルを、ネットワーク部１０７を用いて外部に送信する（ステップ６０３）。例えば、前述のＯＯＭＥ５１４の発生後に回収用ファイル送信処理を行った場合、回収用ファイル"ｈｅａｐｄｕｍｐ＿２０１６０６０１２２００．ｇｚ"と"ｈｅａｐｄｕｍｐ＿２０１６０６１３１２００．ｇｚ"を外部に送信する。なお、外部の送信先は、あらかじめＨＤＤ１０４に記憶していることとする。また、この送信処理は一般的な外部へのファイル送信処理と同じであるため、処理の詳細は省略する。一方、回収用ファイルが存在しない場合、ファイルを送信することなく、処理を終了する。なおステップ６０３の後、送信済みの回収用ファイルをすべて削除してもよい。

以上が、回収用ファイル送信処理である。なおここでは、上記のステップ６０１における送信指示は、操作部１０６でユーザによる入力により発生することとしたが、別の処理により送信指示が発生してもよい。例えば、ステップ４０８で回収用ファイルを生成した後に、回収ファイル生成部３０３からファイル送信部３０６に送信指示を送信することとしてもよい。

以上のように、ステップ４０７とステップ４０８で生成した回収用ファイルを画像形成装置１００の外部に送信することで、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの原因解析が可能となる。なお、ステップ４０５で生成し、ステップ４０９でファイルサイズを変更したヒープダンプファイルについては、外部への送信は行わない。なお本実施形態では、ヒープダンプファイルのファイルサイズを０としているが、その削除に所定時間を超える時間を要しない程度のサイズに縮小するのであれば必ずしも０でなくともよい。また、ヒープダンプファイルを削除するタイミングを本実施形態では画像形成装置１００の電源投入時としたが、たとえばシャットダウン処理の中で行ってもよいし、あるいはユーザが明示的に指示したタイミングで行ってもよい。このように他のタイミングでヒープダンプファイルを削除してもよい。

［第２の実施形態］
第１の実施形態では、ヒープダンプファイルを生成する処理は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生したときに行っていた。しかし、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生しない場合でも、別の条件を基にヒープダンプファイルを生成する処理を実行することも可能である。

本実施形態では、別の条件を基にヒープダンプファイルを生成する処理を、フローチャート図７を用いて説明する。なお、基本的な処理や制御は第１の実施形態と同じであるため、第１の実施形態と異なる点のみを説明する。具体的には、第１の実施形態では、図４のフローチャートのステップ４０３においてＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を待つ処理を行ったが、本実施形態ではこの処理が異なる。

画像形成装置１００の初期化処理時の処理（ステップ４０１〜４０２）は、第１の実施形態と同じである。この後、シャットダウンを検知するまで、エラー検知部３０７は、システム的なエラーが発生したかをどうか判定する（ステップ７０１）。そしてエラーの発生を検知するまで、この判定を繰り返す。なおこのエラーとは、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒだけではなく、ＲＡＭ１０２やＨＤＤ１０４でのアクセスエラーや、操作部１０６からの応答なしエラーなどのＣＰＵ１０１で検知可能な全てのエラーである。そのため、画像形成装置１００で印刷を行う際のトラーなしエラーや、紙つまりエラーなどもエラー検知部３０７で検知可能である。

エラー検知部３０７は、エラーを検知すると、ヒープダンプ生成部３０２に、ヒープダンプ生成要求を送信する。このヒープダンプ生成要求を受信したヒープダンプ生成部３０２は、第１の実施形態と同じく、ＪａｖａＶＭ２０２の起動オプションで指定された生成パスにヒープダンプファイルが存在するかを判定する（ステップ４０４）。そして、存在しないと判定した場合は、ヒープダンプ生成部３０２はヒープダンプファイルを生成する（ステップ４０５）。この詳細の処理は、第１の実施形態と同じであるため、説明を省略する。

以上のように、画像形成装置１００でＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ以外のエラーが発生した場合でも、画像形成装置１００の起動時間に影響を与えずに、ヒープダンプファイルを生成することができる。これにより、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生する直前の状態や、何らかの原因でＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生できないような状況においても、ヒープダンプファイルを用いた原因解析が可能となる。
以上が、第２の実施形態の説明である。また、ログファイルがヒープダンプファイルであるとしているが、エラーの種類に応じた他のログファイルを対象として本実施形態を実現することもできる。また、発生するエラーの種類が変わった場合にヒープダンプファイルを削除してもよい。このようにすることで、異なるエラーが発生した場合に、そのエラーに係るログファイルが保存されることがあり得る。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１ ＣＰＵ、１０２ ＲＡＭ、１０３ ＲＯＭ、１０４ ＨＤＤ、３０１ メモリ制御部、３０２ ヒープダンプ生成部、３０３ 回収ファイル生成部

Claims (10)

1. エラーの発生をトリガとして、ログファイルが無い場合にはログファイルを生成するログファイル生成手段と、
   前記ログファイル生成手段で生成した前記ログファイルを別名のファイルとして保存する別名ファイル生成手段と、
   前記ログファイルのファイルサイズを縮小するファイルサイズ変更手段と、
   前記ファイルサイズ変更手段により前記ファイルサイズを変更した前記ログファイルを、所定のタイミングで削除するファイル削除手段と
   を有することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記別名ファイル生成手段は、前記別名のファイルの名称として前記別名のファイルの新旧を示す情報を含ませ、保存されている前記別名のファイルが所定数を超える場合には、古い方のファイルから削除することを特徴とする情報処理装置。
3. 請求項１または２に記載の情報処理装置であって、
   前記ファイル削除手段は、前記情報処理装置の起動時に前記ログファイルを削除することを特徴とする記載の情報処理装置。
4. 請求項１乃至３のいずれか一項に記載の情報処理装置であって、
   前記エラーは、メモリ不足エラーであり、前記ログファイルは、メモリの割り当てに関する情報を含むことを特徴とする情報処理装置。
5. 請求項４に記載の情報処理装置であって、
   前記エラーは前記情報処理装置で動作するＪａｖａアプリケーションによるＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒであり、前記ログファイルは、ヒープダンプファイルであることを特徴とする情報処理装置。
6. 請求項１乃至５のいずれか一項に記載の情報処理装置であって、
   前記ファイルサイズ変更手段により縮小されるファイルサイズは０であることを特徴とする情報処理装置。
7. 請求項１乃至６のいずれか一項に記載の情報処理装置であって、
   前記別名のファイルを外部に送信する送信手段を更に有することを特徴とする情報処理装置。
8. 請求項７に記載の情報処理装置であって、
   前記送信手段により前記別名のファイルを外部に送信した後、送信済みの前記別名のファイルを削除することを特徴とする情報処理装置。
9. 請求項１乃至８のいずれか一項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。
10. 情報処理装置において、
    エラーの発生をトリガとして、ログファイルが無い場合にはログファイルを生成し、
    生成した前記ログファイルを別名のファイルとして保存し、
    前記ログファイルのファイルサイズを縮小し、
    前記ファイルサイズが変更された前記ログファイルを、所定のタイミングで削除する
    ことを特徴とする情報処理装置の制御方法。

Images