特表 2024-526023 コア・ダンプのための自己最適化分析システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-07-17

(54)【発明の名称】コア・ダンプのための自己最適化分析システム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20240709BHJP

   G06F 16/907 20190101ALI20240709BHJP

【ＦＩ】

G06F11/07 190

G06F11/07 178

G06F16/907

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023572705

(86)(22)【出願日】2022-06-08

(85)【翻訳文提出日】2023-11-24

(86)【国際出願番号】 IB2022055316

(87)【国際公開番号】W WO2022259161

(87)【国際公開日】2022-12-15

(31)【優先権主張番号】17/344,242

(32)【優先日】2021-06-10

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】390009531

【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション

【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】Ｎｅｗ Ｏｒｃｈａｒｄ Ｒｏａｄ， Ａｒｍｏｎｋ， Ｎｅｗ Ｙｏｒｋ １０５０４， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100112690

【弁理士】

【氏名又は名称】太佐 種一

(74)【代理人】

【識別番号】100120710

【弁理士】

【氏名又は名称】片岡 忠彦

(74)【復代理人】

【識別番号】110000420

【氏名又は名称】弁理士法人ＭＩＰ

(72)【発明者】

【氏名】ミュラー、ラファエル

(72)【発明者】

【氏名】ライヒェルト、ミヒャエル

【テーマコード（参考）】

5B042

5B175

【Ｆターム（参考）】

5B042KK08

5B042KK14

5B042KK15

5B042MA08

5B042MA14

5B175FB03

(57)【要約】

コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするための方法が開示される。方法は、ソフトウェア・プログラムに関連するコア・ダンプ・ファイルを受信するステップと、クラッシュ時に実行中スレッドごとに、コア・ダンプ・ファイル内で固有ソース・コード行を識別するステップと、異なるスレッド内での顕著なソース・コード行の発生回数を示す抽象化レベル値に応じて、固有ソース・コード行を顕著なソース・コード行として決定するステップとを含む。さらに、方法は、顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率を決定するステップと、固有ソース・コード行を顕著なソース・コード行として決定し、抽象化率を決定することによって、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、顕著なソース・コード行および抽象化率の評価値を出力するステップとを含む。

【特許請求の範囲】

【請求項1】

コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコンピュータ実装方法であって
－複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－前記ソフトウェア・クラッシュ時に実行中スレッドごとに、前記少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて前記固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、前記抽象化レベル値が、異なるスレッド内での前記顕著なソース・コード行の発生回数を示す、前記決定するステップと、
－顕著なソース・コード行の数および前記固有ソース・コード行の数の関数として抽象化率の値を決定するステップと、
－前記固有ソース・コード行を前記顕著なソース・コード行として決定する前記ステップおよび前記抽象化率の前記値を決定する前記ステップのさらなる反復のために、前記事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－前記顕著なソース・コード行および前記抽象化率の前記値の評価値を出力するステップと
を含む、コンピュータ実装方法。

【請求項2】

出力される前記顕著なソース・コード行は、前記クラッシュ時に実行中スレッド内での出現頻度によって順序付けされる、請求項１に記載の方法。

【請求項3】

前記固有ソース・コード行を識別するステップは、
－所与のクラッシュの根本原因分析に十分である可能性が高いスレッドの部分集合を選択すること
をさらに含む、請求項１または２に記載の方法。

【請求項4】

前記事前定義された抽象化レベルは、前記顕著なソース・コード行の前記決定がどの程度の細粒度で行われるかを示す、請求項１ないし３のいずれかに記載の方法。

【請求項5】

－前記抽象化率の前記値の前記評価値が事前定義された範囲内にあるかどうかを判定するステップ
も含む、請求項１ないし４のいずれかに記載の方法。

【請求項6】

－前記方法の実行に基づいて根本原因分析が成功したかどうかを示す根本原因ヒット値、
－前記抽象化率の関連する値、もしくは
－前記抽象化率の前記値の可能な値の全範囲のバケット・サイズ値に依存する、関連するバケット・インデックス、
またはそれらの組合せを永続的に記憶するステップも含む、請求項１ないし５のいずれかに記載の方法。

【請求項7】

－前記抽象化率の下限閾値もしくは上限閾値またはその両方を決定するステップであって、前記下限閾値および前記上限閾値が、根本原因分析が成功する確率が高いことを表す前記抽象化率の前記値に関する範囲を定義する、前記決定するステップ
も含む、請求項６に記載の方法。

【請求項8】

－グループの他のコア・ダンプ・ファイルに適合しない少なくとも２つのコア・ダンプ・ファイルを含む前記グループからコア・ダンプ・ファイルを選択解除するステップ
も含む、請求項１ないし７のいずれかに記載の方法。

【請求項9】

前記少なくとも１つのコア・ダンプ・ファイルを受信する前記ステップは、
－前記少なくとも１つのコア・ダンプ・ファイルを人間が読める文字に変換すること
も含む、請求項１ないし８のいずれかに記載の方法。

【請求項10】

前記方法は、前記少なくとも１つのコア・ダンプ・ファイルが作成される前に前記ソフトウェア・プログラムが実行されたハードウェア・アーキテクチャに依存しない、請求項１ないし９のいずれかに記載の方法。

【請求項11】

－前記受信した少なくとも１つのコア・ダンプ・ファイルの可能な組合せをコア・ダンプ・ファイルとして構築するステップと、
－（ｉ）前記固有ソース・コード行を識別する前記ステップ、（ｉｉ）前記固有ソース・コード行のそれぞれを前記顕著なソース・コード行として決定する前記ステップ、（ｉｉｉ）前記抽象化率を決定する前記ステップ、および（ｉｖ）前記さらなる反復のために、前記事前定義された抽象化レベル値を調整する必要があるかどうかを評価する前記ステップ、を実行するステップと、
－最も高い抽象化率に関連する出力すべきこれらの顕著なソース・コード行を選択するステップと
も含む、請求項１ないし１０のいずれかに記載の方法。

【請求項12】

コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコア・ダンプ分析システムであって、前記システムが、
－プロセッサに通信可能に結合されたメモリを備え、前記メモリが、前記プロセッサによって実行されたときに、
－複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－前記ソフトウェア・クラッシュ時に実行中スレッドごとに、前記少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて前記固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、前記抽象化レベル値が、異なるスレッド内での前記顕著なソース・コード行の発生回数を示す、前記決定するステップと、
－顕著なソース・コード行の数および前記固有ソース・コード行の数の関数として抽象化率の値を決定するステップと、
－固有ソース・コード行を前記顕著なソース・コード行として決定する前記ステップおよび前記抽象化率の前記値を決定する前記ステップのさらなる反復のために、前記事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－前記顕著なソース・コード行および前記抽象化率の前記値の評価値を出力するステップと
を前記プロセッサが実行することを可能にするプログラム・コード部分を記憶する、コア・ダンプ分析システム。

【請求項13】

出力される前記顕著なソース・コード行が、前記クラッシュ時に実行中スレッド内での出現頻度によって順序付けされる、請求項１２に記載のシステム。

【請求項14】

前記プログラム・コード部分が、前記固有ソース・コード行を識別する間に、
－所与のクラッシュの根本原因分析に十分である可能性が高いスレッドの部分集合を選択すること
を前記プロセッサが実行することも可能にする、請求項１２または１３に記載のシステム。

【請求項15】

前記事前定義された抽象化レベルが、前記顕著なソース・コード行の前記決定がどの程度の細粒度で行われるかを示す、請求項１２ないし１４のいずれかに記載のシステム。

【請求項16】

前記プログラム・コード部分が、
－前記抽象化率の前記値の前記評価値が事前定義された範囲内にあるかどうかを判定するステップ
を前記プロセッサがさらに実行することを可能にする、請求項１２ないし１５のいずれかに記載のシステム。

【請求項17】

前記プログラム・コード部分が、
－グループから選択された少なくとも１つの値、すなわち、
－方法の実行に基づいて根本原因分析が成功したかどうかを示す根本原因ヒット値、
－関連する抽象化率値、および
－前記抽象化率の前記値の可能な値の全範囲のバケット・サイズ値に依存する、関連するバケット・インデックス
を永続的に記憶するステップを前記プロセッサがさらに実行することを可能にする、請求項１２ないし１６のいずれかに記載のシステム。

【請求項18】

前記プログラム・コード部分が
－前記抽象化率の下限閾値もしくは上限閾値またはその両方を決定するステップであって、前記下限閾値および前記上限閾値が、根本原因分析が成功する確率が高いことを表す前記抽象化率に関する範囲を定義する、前記決定するステップ
を前記プロセッサがさらに実行することを可能にする、請求項１７に記載のシステム。

【請求項19】

前記プログラム・コード部分が、
－グループの他のコア・ダンプ・ファイルに適合しない少なくとも２つのコア・ダンプ・ファイルを含む前記グループからコア・ダンプ・ファイルを選択解除するステップ
を前記プロセッサがさらに実行することを可能にする、請求項１２ないし１８のいずれかに記載のシステム。

【請求項20】

コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコンピュータ・プログラム製品であって、階層が、根ノードと、関連する部分木を含む少なくとも１つの子ノードとを含み、前記コンピュータ・プログラム製品が、プログラム命令が具現化されたコンピュータ可読記憶媒体を含み、前記プログラム命令が、１つまたは複数のコンピューティング・システムまたはコントローラによって実行可能であり、前記１つまたは複数のコンピューティング・システムに、
－複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－前記ソフトウェア・クラッシュ時に実行中スレッドごとに、前記少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて前記固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、前記抽象化レベル値が、異なるスレッド内での前記顕著なソース・コード行の発生回数を示す、前記決定するステップと、
－顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率を決定するステップと、
－固有ソース・コード行を前記顕著なソース・コード行として決定する前記ステップおよび前記抽象化率を決定する前記ステップのさらなる反復のために、前記事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－前記顕著なソース・コード行および抽象化率の値の評価値を出力するステップと
を実行させる、コンピュータ・プログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、根本原因分析を容易にするための方法に関し、より詳細には、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコンピュータ実装方法に関する。本発明はさらに、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコア・ダンプ分析システム、およびコンピュータ・プログラム製品に関する。

【背景技術】

【0002】

ソフトウェア開発のスピードは、ソフトウェア会社およびコンサルティング会社だけでなく企業にとっても重要な成功要因となっている。しかしながら、今日の企業ソフトウェア製品のソース・コードのベースは、大規模かつ複雑である傾向にある。これは、イベント・ベースのプログラミング手法およびコンテナ化によって部分的にしか駆動されない。このため、このソフトウェアを保守する際、年功に関係なくあらゆるタイプの開発者にとって課題が生じる。しかしながら、保守段階中だけでなく開発中においても、欠陥のあるプログラム・コードを迅速かつエレガントにデバッグすることが不可欠になっている。

【0003】

こうしたボリュームの問題に対処するためにいくつかのツールが存在しており、そのいくつかは、トピック「Code Spelunking: Exploring Cavernous Code Bases」（例えば、https://queue.acm.＼org/detail.cfm?id=945136を参照）またはトピック「Code Spelunking Redux」（https://queue.acm.＼org/detail.cfm?id=1483108を参照）で説明されている。

【0004】

膨大な量のソース・コード以外にも、企業ソフトウェア自体の性質には、複雑であるという別の側面がある。企業ソフトウェアにより、ユーザは、同じ種類のタスクを同時に高速で実行することが可能になるが、各タスクは同じ種類のリソースで競合している可能性がある。したがって、今日の企業ソフトウェアは、マルチタスク方式およびマルチスレッド方式で稼働／作用する。例えば、リレーショナル・データベース管理システム（ＲＤＢＭＳ）は、複数の並列ストリームを使用して、同じデータにアクセスする可能性がある大量の同時トランザクションに対処することができる。

【0005】

適切に処理されないエラーが発生した場合、ソフトウェア自体が、アクティブな各実行ユニットの診断情報、すなわち、すべてのプロセスおよびそれに関連するスレッドの診断情報を書き出す、つまりシステム・リソースを活用して診断情報をダンプする。このタイプのエラーの例は、デッドロック、無限ループ、保護されたメモリへのアクセス、またはすでに存在していないメモリなどである。診断データは、障害発生時のプロセス状態のスナップショットを表してもよい。これは、レジスタ値、割り当てられたメモリ、各スレッドの状態およびコール・スタックなどを含むことができる。

【0006】

Ｕｎｉｘ（登録商標）系オペレーティング・システムの文脈では、これらのスナップショットはコア・ダンプまたはコア・ダンプ・ファイルと呼ばれる。企業ソフトウェアは、実行時にステータスおよび診断情報を利用可能なトレーシング機能へトレースするが、次の理由、すなわち（ｉ）現在の問題に利用できる好適なトレースがない、すなわち、ソース・コード内のトレース（トレーシング）情報が不十分であることが原因である、（ｉｉ）現在アクティブなトレーシング・レベルが低すぎることが原因で、トレース・ファイルに重要な情報が欠落している、または（ｉｉｉ）問題発生時のシステムのワークロードに起因して、より最新のトレース情報を有するトレース・ファイルをラウンド・ロビンで使用していることが原因で、対象となるトレーシング情報がすでに上書きされている、という理由から、ソフトウェア開発者は多くの場合、寄与するすべてのプロセスの診断データもしくは関与するすべてのプロセスのコア・ダンプまたはその両方を分析する必要がある。

【0007】

したがって、コア・ダンプ自体は人間により判読不可能であり、したがって、ソフトウェア開発者は、それらを前処理するスキルが必要になる場合がある。しかしながら、このスキルが欠けていない場合でも、次の理由、すなわち（ｉ）問題の根本原因を発見するために、どのコア・ダンプが関連しているか分からない、または（ｉｉ）問題の根本原因を発見して問題を解決するために、フォーマットされたコア・ダンプで何を探すべきか分からない、という理由から、コア・ダンプを分析することは簡単な作業ではない。

【0008】

分析することが常に困難である１つの障害クラスは、デッドロックおよび無限ループなどのハング状況である。

【0009】

文書ＣＮ１０６３５６４６Ａのような同様の問題に対処する公開がすでに存在する。これは、ダンプ・ファイルを分析するための方法を開示しており、方法は、第１のステップにおいて、ソフトウェアが崩壊したときに、生成されたダンプ・ファイルおよび他の関連する崩壊情報ファイルを取得することと、ダンプ・ファイルおよび関連する崩壊情報ファイルをストレージに送信することと、ソフトウェア・モジュールに従ってストレージ・エンドを通じて崩壊情報ファイルを分類、圧縮、および記憶することと、ダンプがダウンロードされたウェブページを自動的に開いてログインすることとを含む。開示された方法は、分析結果が得られた時点で分析結果ログを確認するよう注意喚起するとともに、繰り返しの確認を回避できるように確認済みの分析ログにマークを付けて区別することも開示している。

【0010】

さらに、ａｃｍｑｕｅｕｅにおいて公開された、George V. Neville-Neilによる論文「Code Spelunking Redux」、および２０２１年２月１５日にhttps://queue.acm.org/detail.cfm? is=148-3108で公開された関連するオンライン版では、コンピュータ・システムのプログラミングがますます複雑になっていること、および基本的にこれがコード・スペランカ（spelunker）に不利に作用することが開示されている。文書では、コンピュータがより強力になっていること、ならびに、コード行、モジュールの数、システムおよびサブシステムの数を含む多くの方向でプログラミングの複雑さが増していることを説明する。依存するソフトウェア・モジュールのグラフィック表現を含めて、ソース・コード内のエラーを発見する様々な選択肢について説明している。

【0011】

しかしながら、既存の根本原因分析システムおよび方法の欠点のうちの１つは、これらが特定のハードウェア・アーキテクチャに大きく依存していることである。さらに、分析することが常に困難である１つの障害クラスは、デッドロックおよび無限ループのような、いわゆる「ハング状況」である。

【0012】

したがって、「ハング状況」もしくはソフトウェア・クラッシュまたはその両方の問題を克服し、ソフトウェア・クラッシュ後に、より簡単でよりターゲットを絞った根本原因分析のための解決策を提案する必要があり得る。

【発明の概要】

【0013】

本発明の一態様によれば、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコンピュータ実装方法が提供され得る。方法は、複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、ソフトウェア・クラッシュ時に実行中スレッドごとに、少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行（unique source code line）を識別するステップと、事前定義された抽象化レベル値に応じて固有ソース・コード行のそれぞれを顕著な（conspicuous）ソース・コード行として決定するステップとを含んでもよい。抽象化レベル値は、異なるスレッド内での顕著なソース・コード行の発生回数を示してもよい。

【0014】

方法はさらに、顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率を決定するステップと、固有ソース・コード行を顕著なソース・コード行として決定するステップおよび抽象化率を決定するステップのさらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、顕著なソース・コード行および抽象化率の値の評価値を出力するステップとを含んでもよい。

【0015】

本発明の別の態様によれば、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコア・ダンプ分析システムが提供される。システムは、プロセッサに通信可能に結合されたメモリを備え、メモリは、プロセッサによって実行されたときに、複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、ソフトウェア・クラッシュ時に実行中スレッドごとに、少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、事前定義された抽象化レベル値に応じて固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップとをプロセッサが実行することを可能にするプログラム・コード部分を記憶する。抽象化レベル値は、異なるスレッド内での顕著なソース・コード行の発生回数を示してもよい。

【0016】

プログラム・コード部分は、顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率を決定するステップと、固有ソース・コード行を顕著なソース・コード行として決定するステップおよび抽象化率を決定するステップのさらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、顕著なソース・コード行および抽象化率の値の評価値を出力するステップとをプロセッサが実行することも可能にしてもよい。

【0017】

コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするための提案されたコンピュータ実装方法は、複数の利点、技術的効果、寄与、もしくは改善、またはそれらの組合せを提供することができる。

【0018】

システム・クラッシュ、特にアプリケーション・ソフトウェア・プログラム・クラッシュの根本原因を探している分析者／プログラマにとっての直接的な利点は、自身がウォーク・スルーおよび分析を行わなければならない可能性があるデータ量が大幅に削減され得ることである。顕著なソース・コード行を比較的高い確率で識別することによって、分析者／開発者は、自分のタスクを実行するために、すなわちシステムをクラッシュさせる「バグを発見する」ために、多くの貴重な時間および労力を節約することができる。

【0019】

この大幅に削減されたデータ量と、抽象化レベルに応じて並行して実行される可能性があるスレッドのうちの２つ以上に出現し得る顕著なソース・コード行の強調表示とに基づいて、分析者／開発者は、高い確率で企業ソフトウェア・プログラムの不良または機能不全の原因となり得るこれらのソース・コード行を正確に受け取ることができる。

【0020】

さらに、利用可能な解決策とは対照的に、本明細書で提案される概念は、基礎となるハードウェア・アーキテクチャおよびソフトウェア・アーキテクチャから独立している。したがって、多大な労力を費やすことでしか企業ソフトウェア・プログラムのソース・コードへのリンクを確立し得ない特定のＣＰＵレジスタもしくはメモリ・レジスタまたはデータ・ストレージ・セルの読出しは存在しない。本発明の概念は、ソフトウェア・クラッシュ時に並行して実行されているスレッド内に存在するこれらの固有ソース・コード行がソフトウェア・クラッシュに関与する確率が高い場合があるとの仮定に依拠し得る。方法および関連するシステムは、抽象化レベルに応じて、例えば、１つだけ、２つ、もしくは３つ、またはそれ以上の並列実行スレッド内に出現するソース・コード行を考慮する。この事実、すなわち複数のスレッド間の相関関係には、有利な技術的効果の１つが見られる可能性がある。マルチカーネル・アーキテクチャによるマルチスレッド実行をサポートする、マルチスレッドの企業（および、他の）アプリケーションならびにハードウェア・システムの普及により、デッドロック状況だけでなく実行中の他のすべての種類の望ましくないソフトウェア挙動（例えば、突然のクラッシュ、無限ループ、保護されたメモリへのアクセス、またはすでに存在していないメモリ）も識別するための効果的な分析ツールが必要とされている。本明細書で提案される概念の、並行して実行されているスレッドを調査する能力は、分析者／プログラマにとって特に有益なものになる可能性がある。

【0021】

以前に実行されたソース・コード分析の履歴データを並行して使用するとともに、推奨範囲の決定、具体的には、抽象化率のパーセンテージに対する下限閾値範囲値の調整が実行されてもよい。実施形態の１つでは、抽象化率の上限閾値が事前定義された値、例えば９０％に固定され得ると仮定されてもよい。提案された概念のこの自己最適化は、実行されるコア・ダンプ分析が多いほど、その概念をさらに有益なものにする可能性がある。したがって、最終的な根本原因分析が成功したか否か、すなわち、ＲＣＨ＝１であるかＲＣＨ＝０であるか（以下を参照）は問題にならない。

【0022】

専門家の判断における別の利点は、自動的な根本原因分析が開発者の見解に近いことであり得る。生成された出力は、プログラム・コード内の修正が必要であり得る領域を示唆する場合もある。したがって、出力はレジスタ、フラグ状態、およびプロセッサ・サイクルではないが、実際に実施可能なアドバイスが平文で人間が読みやすい形式で開発者に提供され得る。

【0023】

以下では、方法およびシステムに適用可能な本発明の概念のさらなる実施形態について説明する。

【0024】

方法の有利な実施形態によれば、出力された顕著なソース・コード行は、クラッシュ時に実行中スレッドにおける出現頻度によって順序付けされてもよい。この順序付けにより、開発者およびクラッシュ分析者は、クラッシュ時に実行中スレッドと問題のあるソース・コード行との間の概要を直接把握できるようになる。これは、根本原因分析を有望な方向に導く可能性がある。

【0025】

方法のさらなる有利な実施形態によれば、固有ソース・コード行を識別するステップは、具体的には固有ソース・コード行のそれぞれを顕著なソース・コード行として決定する前に、所与のクラッシュの根本原因分析に十分である可能性が高いスレッドの部分集合を選択することをさらに含んでもよい。これは、例えば、プログラムされた時間依存の遅延または時間指定された待機に関する待機ステータスを有するこれらのスレッドを除外することを含んでもよい。このようなスレッドの特徴は、予め決められた時間が経過すると再び起動されるということである。したがって、これらのスレッドが顕著なソース・コード行に寄与する可能性はほとんどない場合がある。

【0026】

方法の有用な実施形態によれば、事前定義された抽象化レベルは、顕著なソース・コード行の決定がどの程度の細粒度で行われるかを示してもよい。抽象化レベルは、例えば、低、中、または高のような３つの異なるレベルで管理されてもよい。経験上、３つのカテゴリのこの抽象化のレベルを用いると、根本原因分析の良好な結果が達成され得ることが分かっている。しかしながら、抽象化レベルの他の粒度レベルも可能である（例えば、４レベル、または５レベル、または６レベル、またはさらには１０レベル）。

【0027】

好ましい実施形態によれば、方法はまた、出力される、すなわちユーザに見えるようにされる、抽象化率の値の評価値が、事前定義された範囲内にあるかどうかを判定するステップを含んでもよい。抽象化率値を特定の値範囲にすると、根本原因分析が短時間で成功する可能性が大幅に高まる可能性がある。したがって、抽象化率値が範囲内にない場合、方法は、別の抽象化レベルを用いて繰り返されてもよい。

【0028】

さらに発展した実施形態によれば、方法はまた、根本原因分析の成功または不成功に関連するデータのセット、すなわち、（ｉ）方法の実行に基づいて根本原因分析が成功したかどうかを示す根本原因ヒット値、および典型的には常に、（ｉｉ）関連する抽象化率値、もしくは（ｉｉｉ）抽象化値の可能な値の全範囲のバケット・サイズ値に応じた関連するバケット・インデックス、またはそれらの組合せを永続的に記憶するステップを含んでもよい。このために、抽象化率値に対して（範囲値を表す）バケットが構築されてもよく、特定の抽象化率値が、そのバケットの中へグループ化されてもよい。一例として、抽象化率値が０％から１００％までの範囲であり得、１０個のバケットが指定され得る場合、３５％の抽象化率値は、第４のバケットに分類されてもよい。したがって、第１のバケットは０％から１０％までの範囲を表し、第２のバケットは１１％から２０％までの範囲を表し、第３のバケットは２１％から３０％までの範囲を表し、第４のバケットは３１％から４０％までの範囲を表し、以下同様であると仮定される。同じ例に対して２０個のバケットによるスキーマが使用される場合、３５％の抽象化率値は、３１％から３５％までの範囲の第７のバケットに分類されてもよい。

【0029】

許容される一実施形態によれば、方法はまた、抽象化率の下限閾値もしくは上限閾値またはその両方を決定するステップを含んでもよい。したがって、下限閾値および上限閾値は、根本原因分析が成功する確率が高いことを表す抽象化率に関する領域または値範囲を定義してもよい。この決定のために、例えばベイズ定理に基づいて、過去のコア・ダンプ分析ならびに成功および不成功の根本原因分析に適用される前述のバケット化および統計的方法が使用されてもよい。

【0030】

有用な実施形態によれば、方法は、グループの他のコア・ダンプ・ファイルに適合しない少なくとも２つのコア・ダンプ・ファイルを含むグループからコア・ダンプ・ファイルを選択解除するステップをさらに含んでもよい。コア・ダンプ・ファイルが別のコア・ダンプ分析の問題に関連しており（例えば、異なるアプリケーションに由来するものであり）、そのため、問題としているコア・ダンプ・ファイルには共通のソース・イベントが存在しないことが判明する場合がある。したがって、提案された方法の場合、同じ種類のソフトウェア・プログラムの問題に関連するコア・ダンプ・ファイルのみが、提案された概念の入力として使用されてもよい。

【0031】

さらなるエレガントかつ有用な実施形態によれば、方法はまた、少なくとも１つのコア・ダンプ・ファイルを可読文字、具体的には人間が読める形式に変換するステップを含んでもよい。このために、既存のツールを容易に使用することができる。一例は、ＧＮＵデバッガｇｄｂであり得る。

【0032】

さらなる有利な一実施形態によれば、方法は、少なくとも１つのコア・ダンプ・ファイルが作成される前にソフトウェア・プログラムが実行されたハードウェア・アーキテクチャに依存しない場合がある。したがって、特にコア・ダンプ分析の最先端技術と比較した場合、本明細書で提案される概念は、事前訓練されたシステム、具体的には特定のソフトウェア・スタック用のシステムに依存しない。

【0033】

先進的な実施形態によれば、方法はまた、受信した少なくとも１つのコア・ダンプ・ファイルの可能な組合せ、具体的には可能なすべての組合せをコア・ダンプ・ファイルとして構築するステップと、（ｉ）固有ソース・コード行を識別するステップ、（ｉｉ）前記固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップ、（ｉｉｉ）抽象化率を決定するステップ、および（ｉｖ）さらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップを実行するステップと、最も高い抽象化率に関連する出力すべきこれらの顕著なソース・コード行を選択するステップとを含んでもよい。したがって、プログラムの問題の解決、すなわちクラッシュしたソフトウェア・プログラムの根本原因の発見に役立つ可能性が最も高い顕著なソース・コードが分析者／開発者に提示されてもよい。これが不可能な場合、次に低い抽象化率（ＡＲ：Abstraction Ratio）に関連する次善の結果が分析者／開発者に表示されてもよく、分析者／開発者は、根本原因が識別および修正されるまで、目下の問題の解決を試みてもよい。

【0034】

さらに、実施形態は、コンピュータもしくは任意の命令実行システムによってまたはそれに関連して、使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセス可能な、関連するコンピュータ・プログラム製品の形式をとってもよい。この説明のために、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、命令実行装置、もしくは命令実行デバイスによってまたはそれに関連して使用するためのプログラムを記憶、通信、伝播、または伝達するための手段を含み得る任意の装置であってもよい。

【0035】

本発明の実施形態は、異なる主題を参照して説明されることに留意されたい。具体的には、いくつかの実施形態は方法タイプの請求項を参照して説明されるが、他の実施形態は装置タイプの請求項を参照して説明される。しかしながら、当業者であれば、上記および以下の説明から、特に断りのない限り、１つのタイプの主題に属する特徴の任意の組合せに加えて、異なる主題に関連する特徴間、具体的には方法タイプの請求項の特徴と装置タイプの請求項の特徴との間の任意の組合せもまた本文書内で開示されるものとみなされると推測するであろう。

【0036】

本発明の上記で定義された態様およびさらなる態様は、以下に説明する実施形態の例から明らかとなり、実施形態の例を参照して説明されるが、本発明はこれらに限定されない。

【0037】

単に例として、本発明の好ましい実施形態を以下の図面を参照して説明する。

【図面の簡単な説明】

【0038】

【図1】コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするための本発明のコンピュータ実装方法の一実施形態のブロック図である。

【図2】コア・ダンプ分析ワークフローに統合された一実施形態のブロック図である。

【図3】提案された概念の一実施形態をより詳細でより実装に近い形式で示したブロック図である。

【図4】複数のコア・ダンプを考慮した、拡張された実施形態のブロック図である。

【図5】コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするための本発明のコア・ダンプ分析システムの一実施形態のブロック図である。

【図6】図５によるシステムを備えるコンピューティング・システムの一実施形態を示す図である。

【発明を実施するための形態】

【0039】

この説明の文脈では、以下の規則、用語、もしくは表現、またはそれらの組合せが使用される場合がある。

【0040】

「根本原因分析」（ＲＣＡ：root cause analysis）という用語は、問題またはイベントの核心的な理由およびそれらに対応するための手法を識別するための、知られている体系的なプロセスを指す場合がある。ＲＣＡは、エラーを調査するには、発生した問題に単に「対処する」だけではなくその問題を防止するための方法を見出す必要があり得るという基本的な前提に基づいている。これは、ソフトウェア・プログラム・クラッシュの根本的な理由を見出すのに十分に適用可能である場合がある。

【0041】

「ソフトウェア・クラッシュ」という用語は、企業アプリケーションなどのコンピュータ・プログラムが適切に動作しなくなり終了する、すなわちその実行を停止するイベントを指す場合がある。

【0042】

「コア・ダンプ分析」という用語は、ソフトウェア・クラッシュ後に、例えばコア・ダンプ・ファイルの形式で生成され得る情報を診断するプロセスを指す場合がある。これは、ソフトウェア・プログラムが適切な実行を停止したアドレスまたはシステム・ステータスに関する情報を含むバイナリ・ファイルである場合がある。

【0043】

「コア・ダンプ・ファイル」という用語は、システムまたはソフトウェアのクラッシュ時のシステム、メモリ、および他の変数の情報を含む前述のバイナリ・ファイルを指す場合がある。ｇｄｂ（ｇｎｕデバッガ）を使用した変換後、バイナリ・コア・ダンプ・ファイルは、人間が読めるコア・ダンプ形式に変換されてもよい。ソース・コード行、例えば、コア・ダンプ・ファイル内の固有ソース・コード行または分析されたソース・コード行について言及する場合、読出し可能な形式に変換されたバージョンを意味する。

【0044】

「ソフトウェア・プログラム」という用語は、コンピュータ・プログラミング言語で記述されたコンピュータ・プログラム、および実行されるように機械可読形式に変換された可能性のあるコンピュータ・プログラムを指す場合がある。

【0045】

「スレッド」という用語は、典型的にはオペレーティング・システムの一部であり得るスケジューラによって独立して管理され得るプログラム命令の最も小さいシーケンスを指すか、またはそれに関連する場合がある。マルチプロセッサ・コンピュータ・システム上の複数のユーザのパフォーマンスを向上させるために、最新の企業アプリケーションは、非常に多くの場合、複数の異なるスレッドによって実行されるが、複数の同一のスレッドによっても実行され得る。

【0046】

「固有ソース・コード行」という用語は、コンピュータ・プログラム内で頻繁に出現し得るが、ソース・コード行がすべてのスレッドおよびすべてのコア・ダンプ・ファイルにわたる固有ソース・コード行になるように一度だけリストされる、コンピュータ・プログラムの行（すなわち、ソース・コード）を指す場合がある。

【0047】

「顕著なソース・コード行」という用語は、ソフトウェア・クラッシュ時（またはその直前）に実行された複数の異なるスレッドに現れ得る固有ソース・コード行のうちの１つまたは複数を指す場合がある。固有ソース・コード行が顕著なソース・コード行としてラベル付けされ得るかどうかは、抽象化のレベル、すなわち抽象化レベルに依存する可能性がある。一般的な規則として、抽象化レベルが高くなるほど、より多くの並列実行スレッドが同じ固有ソース・コード行を含むべきである。

【0048】

「抽象化レベル」という用語は、同じ固有ソース・コード行が存在する、ソフトウェア・クラッシュ時に実行されている並列実行スレッドの数に関連する場合がある。

【0049】

「抽象化率」という用語は、識別された固有ソース・コード行および関連する顕著なソース・コード行を使用した関数を指す場合がある。一例は、以下に説明された式（１）によって表される。固有ソース・コード行に基づく場合、アルゴリズムが推奨事項（すなわち、ソフトウェア・クラッシュの原因となる顕著なソース・コード行）を見つけ出すことがより困難になり得るので、抽象化率は分析結果の品質を判断するのに好適である場合がある。

【0050】

高い率を見つけ出すために、アルゴリズムに求められることは、少数の顕著なソース・コード行を返すことだけである。さらに、実際の企業ソフトウェアの欠陥の純粋な人間による根本原因分析と比較した以下に与えられる式（式（１）を参照）は、エラーを迅速に識別するための非常に優れた手段である。これに基づいて、抽象化率の最良の実践的な範囲が導出された。さらに、実験により、単純化率ｒｓ（例えば、ｒｓ＝［１－（固有ソース・コード行）／（分析されたソース・コード行）］）が、根本原因分析支援システムの品質を証明するにははるかに悪い変数であることも証明され得る。

【0051】

「評価値」という用語は、結果として得られる抽象化率が、抽象化率の下限閾値から抽象化率の上限閾値までの推奨範囲内にあり得るかどうかの指標を指す場合がある。

【0052】

「バケット・インデックス」という用語は、ある特定の値が関連し得るバケットのインデックスを指す場合がある。測定範囲が、例えば１０個のバケットに分割され得る場合、バケット・インデックスは、１から１０まで（または０から９まで）の範囲であってもよい。したがって、５８％のパーセンテージ値が決定された場合、それは第６のバケットに関連していてもよく、したがって、バケット・インデックスは６である。

【0053】

図面の説明に移る前に、本発明の概念を複数のステップでより概略的に説明する。

【0054】

ステップ１―コア・ダンプ・ファイルをフォーマットする：利用可能なコア・ダンプ・ファイルのセットが、人間が読めるように自動的に前処理される；利用可能なコア・ダンプ・ファイルのセットは、バイナリ形式からテキスト形式に変換される。

【0055】

ステップ２―関連するコア・ダンプ・ファイルの最小限のセットを選択する：目下の問題の根本原因分析をさらに進めるのに十分であるという信頼度の高い部分集合を決定するために、フォーマットされたコア・ダンプ・ファイルのセットが分析されてもよい。このステップの結果は、信頼度によって順序付けされたコア・ダンプ部分集合のリストであってもよい。このリストの先頭は、最初のコア・ダンプ部分集合、すなわち、最も信頼度の高い部分集合であってもよい。

【0056】

ステップ３―コア・ダンプを分析し、評価レポートを作成する：ステップ２で決定された順序付けされたコア・ダンプ部分集合のリストの先頭が分析されてもよい。これにより、（ｉ）ソース・コード行、および（ｉｉ）両方とも問題に寄与する確率が高いスレッド、の第１の評価がもたらされてもよい。

【0057】

初期の診断データと比較して、評価結果は、最終的に、分析者／ソフトウェア開発者が根本原因を識別するために検討しなければならない情報の量を大幅に削減することができる。

【0058】

ステップ４―開発者フィードバック：ソフトウェア開発者がステップ３で提供されたコア・ダンプ・ファイルのセットを使用して目下の問題を徹底的に分析できた場合、手順はここで終了してもよい。それ以外の場合、コア・ダンプ部分集合の先頭が１つだけ繰り上がってもよく、ステップ３で手順が繰り返される。いずれの場合も、フィードバック結果は記憶されてもよく、永続性データ・ストア内のコア・ダンプ部分集合および信頼値をステップ２にフィードバックして、部分集合の選択を改善することができる。

【0059】

次に、４つのステップの手法に基づいて、４つのステップ、およびさらに５つ目のステップをより詳細かつより例示的に見てゆく。

【0060】

ステップ１：

【0061】

Ｕｎｉｘ（登録商標）系オペレーティング・システムでは、コア・ダンプは、ｇｎｕデバッガ（ｇｄｂ）によって、バイナリ・ダンプを人間が読めるファイルに変換するように処理され得る。例えば、以下のコマンドは、ある特定の実行可能ファイルの現在のコール・スタックを含むすべてのスレッドの情報を含む、人間が読める出力を生成することができる。
gdb executable --core core.file --batch --quiet ＼
-ex "thread apply all bt full" -ex "quit" > core.file.resolved

【0062】

ステップ２：

【0063】

方法は、空集合を無視して、Ｃを現在の部分集合として使用して、コア・ダンプ冪集合のすべての要素を反復してもよい。したがって、無視できるすべてのスレッド、例えば、時間指定された待機を行うスレッドはタイマがそのスレッドを呼び起こすまで待機するので、除外する。

【0064】

残りのスレッドについては、現在の部分集合ＣのＮ個の抽象化率ＡＲが決定される。Ｎ＝３の場合を使用すると、以下のカテゴリが決定される。
－Ｃａｔ＿１：すべてのコア・ダンプ内の少なくとも１つの実行中スレッドで発生するすべてのソース・コード行。これは、顕著なソース・コード行のセットＳＬＣａｔ＿１を表す。
－Ｃａｔ＿２：すべてのコア・ダンプ内の少なくとも２つの実行中スレッドで発生するすべてのソース・コード行。これは、顕著なソース・コード行のセットＳＬＣａｔ＿２を表す。
－Ｃａｔ＿３：すべてのコア・ダンプ内の少なくとも３つの実行中スレッドで発生するすべてのソース・コード行。これは、顕著なソース・コード行のセットＳＬＣａｔ＿３を表す。

【0065】

次いで、抽象化率は、以下のように算出されてもよい。
－ＡＲ＿１＝１－ＳＬＣａｔ＿１／ｓｌｕ
－ＡＲ＿２＝１－ＳＬＣａｔ＿２／ｓｌｕ
－ＡＲ＿３＝１－ＳＬＣａｔ＿３／ｓｌｕ
ここで、ｓｌｕ＝固有ソース・コード行数である。

【0066】

部分集合Ｃについては、ＳＬＣａｔ_ｎと、例えば４５％（ＡＲ_ｌｏｗ下限）から例えば９０％（ＡＲ_ｕｐ上限）の範囲内で最も高いＡＲ_ｎとがリストＬに記憶されてもよい。したがって、Ｌは、抽象化率によって振り分けられた、（Ｃ、ＳＬＣａｔ_ｎ、ＡＲ_ｎ）からなる３つ組（triple）のリストであってもよい。

【0067】

ステップ３：

【0068】

次に、ステップ２で作成されたリストＬの先頭に、セットＳＬＣａｔ_ｎが表示されてもよい。ＳＬＣａｔ_ｎに基づいて、問題に関するスレッドベースのビューが提示され得る。例えば、コア・ダンプごと、スレッドごとに、疑わしいソース・コード行の数またはステートメント・テキストが表示され得る。次いで、提供された情報を用いて根本原因分析が続行されてもよい。

【0069】

ステップ４：

【0070】

最後に、根本原因ヒットＲＣＨ（ブール値、問題解決／未解決）、使用されたＡＲは永続データ・ストアに記憶される。永続性データ・ストアによって使用される変数は次の通りである。
ＲＣＨ＝根本原因ヒット、ブール値
ＡＲ＝抽象化率（パーセント）
ＡＲ１０Ｂ＝抽象化率バケットであり、バケットの範囲は、１０％の粒度で０から９まで様々である
ＡＲ５Ｂ＝抽象化率バケットであり、バケットの範囲は、５％の粒度で０から１９まで様々である

【0071】

このようなテーブルの一例を次に示す。

【0072】

【表1】

【0073】

問題が解決されない（ＲＣＨ＝０であり、根本原因が識別されない）場合、Ｌに記憶されている次の３つ組を使用して、ステップ３が繰り返される。

【0074】

ステップ５：

【0075】

十分なユーザ・フィードバックが収集されると、ステップ２でのＡＲ_ｌｏｗを適応させるために、成功した問題解決のデータを使用して新しいＡＲ_ｌｏｗが決定される。これは、例えばベイズ定理を使用して実施され得る。

【0076】

Ｐ（Ａ｜Ｂ）＝［Ｐ（Ａ）＊Ｐ（Ｂ｜Ａ）］／Ｐ（Ｂ）

【0077】

ここで、Ｐ（Ａ｜Ｂ）は、条件Ｂの下でのイベントＡの確率Ｐを定義する。

【0078】

したがって、Ａ＝＞（ＲＣＨ＝＝１）、すなわち、イベントＡは根本原因ヒットを表し、Ｂ_ｉ＝＞（ＡＲ５Ｂ＝＝ｉ）、すなわち、イベントＢ_ｉはＡＲ５Ｂ_ｉの使用を表す。

【0079】

例えば、５％の抽象化率バケット粒度を使用すると、確率（Ａ｜Ｂ_ｉ）は、以下のように算出され得る。
Ｐ（Ａ）＝［ＲＣＨの数］／（分析の数）
Ｐ（Ｂ_ｉ）＝［分析に使用されるＡＲ５Ｂ_ｉの数］／（分析の数）
Ｐ（Ｂ_ｉ｜Ａ）＝［ＡＲ５Ｂ_ｉを使用した分析の成功数］／［分析の成功数］
Ｐ（Ａ｜Ｂ_ｉ）＝Ｐ（Ａ）＊Ｐ（Ｂ_ｉ｜Ａ）／Ｐ（Ｂ_ｉ）
したがって、ＡＲ_ｌｏｗを適応させるためにステップ２でＭＡＸ（（Ａ｜Ｂ_ｉ））が使用される。

【0080】

以下では、図について詳細に説明する。図中のすべての解説は概略的なものである。最初に、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするための本発明のコンピュータ実装方法の一実施形態のブロック図が与えられる。その後、さらなる実施形態、ならびにコア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコア・ダンプ分析システムの実施形態について説明する。

【0081】

図１は、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコンピュータ実装方法１００の好ましい実施形態のブロック図を示す。上記から導き出されるように、根本原因分析は主に、デバッグのサポート、すなわち、特にクラッシュ後にソフトウェア・プログラム内のエラーを発見することに関係する。方法は、複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップ１０２を含む。典型的には、通常は同じタイプのアプリケーションを起源とする２つ以上のコア・ダンプ・ファイルが利用可能であることが理解される。それ以外の場合、異常な結果しか期待できない。

【0082】

方法１００はまた、ソフトウェア・クラッシュ時に実行中スレッドごとに、少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップ１０４と、事前定義された抽象化レベル値に応じて固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップ１０６とを含む。抽象化レベル値は、プロセスの開始時に、例えばユーザから受信され得る。したがって、抽象化レベル値は、異なるスレッド内での顕著なソース・コード行の発生回数を示す。

【0083】

この時点で、以下が中間結果となり得る：
分析されたソース・コード行の数（ｓｌａ）：４８１（すなわち、すべてのコア・ダンプ内で見出されたすべての行）
固有ソース・コード行の数（ｓｌｕ）：７６（すなわち、重複はｓｌａから削除される）
顕著なソース・コード行の数：１７（すなわち、顕著であるとアルゴリズムがみなしたｓｌｕのこれらのソース・コード行）

【0084】

さらに、方法１００は、例えば以下の形式で、顕著なソース・コード行の数および固有ソース・コード行の数ｓｌｕ_ｉの関数として抽象化率（ＡＲ）を決定するステップ１０８を含む。
所与のスレッドの場合、
ＡＲ＝１－ｓｌｃ／ｓｌｕ （１）
式中、
ｓｌｃ＝顕著なソース・コード行の数、および
ｓｌｕ＝固有ソース・コード行の数
である。

【0085】

さらに、方法１００は、固有ソース・コード行を顕著なソース・コード行として決定するステップおよび抽象化率を決定するステップのさらなる反復のために、事前定義された抽象化レベル値、すなわち入力パラメータを調整する必要があるかどうかを評価するステップ１１０を含む。これは、例えば、受信された根本原因ヒット（ＲＣＨ）値、すなわち、ソフトウェア・クラッシュの根本原因が人間の分析者によって発見されたか、またはＡＲ値が悪すぎるためであるかに基づいてもよい。

【0086】

さらなるステップでは、方法１００は、顕著なソース・コード行と、具体的にはパーセンテージ値の形式における抽象化率の値の評価値とを出力するステップ１１２を含む。

【0087】

説明された方法１００のさらなる任意選択として、収集されたデータ（ＲＣＨ値、ＡＲ値、バケット・インデックス値など）に基づくＡＲ_ｌｏｗの適応が実行されるべきかどうかを積極的に評価することも可能である。したがって、この場合、評価は、ＡＲが最良の実践的な範囲内にあり得るかどうか、またはベイズ定理によってＡＲ_ｌｏｗを決定し、適応を実行し、次のステップとして値範囲のテストを実行するために十分なデータが利用可能かどうかを最初に確認（すなわち、決定）するかどうかという形式で解釈可能になる。

【0088】

図２は、コア・ダンプ分析ワークフローに統合された一実施形態２００のブロック図を示す。ブロック２０１は、複数の並列スレッド２０３を有し得る実行されたソフトウェア・プログラムを表すものとし、複数の並列スレッド２０３の多くは同一であってもよい。例えば、通常、大規模なユーザ・コミュニティが同じまたは類似のタスクを実行するマルチユーザ・システムであるデータベース・システムまたは企業アプリケーションでは、ほとんどの場合、アプリケーションの全体的な性能を向上させるために、同一のスレッドが実行されるかまたは並行して実行される。

【0089】

プログラム・コードのエラーにより開始された時間「ｔ」の後に、プログラム・コードの実行が中断する、または完全に停止する、すなわちクラッシュすること（２０６）が発生し得る。これにより、コア・ダンプ・ファイル２０２が生成される。典型的には、システム・レベルのルーチンがこれを担う。

【0090】

少なくとも１つのコア・ダンプ・ファイル２０２は、あるバージョンの提案されたコア・ダンプ分析システム２０８に供給される。さらに、抽象化レベル２０４（抽象化率と混同すべきではない）もコア・ダンプ分析システム２０８に入力されてもよい。上記で説明された方法１００に基づいて、コア・ダンプ分析システム２０８は、具体的にはユーザに可読形式で、顕著なソース・コード行２１８、抽象化率２２０の値を抽象化率２２０の関連する範囲２２２と共に出力する。この情報、特に、顕著なソース・コード行は、ソース・コード分析者／プログラマが自分の根本原因分析２１２を実行するために使用され得る。次いで、実行された提案された方法からのいずれかのデータ、すなわち、顕著なソース・コード行２１８、使用された抽象化レベル２０４、決定された抽象化率２２０、および範囲２２２と共に、成功したか否かが、根本原因ヒット値２１４（ＲＣＨ）の形式でデータ・ストレージ２１０に永続的に記憶され得る。

【0091】

図３は、提案された概念の一実施形態３００をより詳細でより実装に近い形式で示したブロック図である。コア・ダンプ・ファイル２０２および抽象化レベルＡＬ２０４（図２も参照）が受信された後、プロセスはコア・ダンプ・ファイルを分析するステップ３０２から開始し、スレッドごとに複数の固有ソース・コード行３０４が得られる。プロセスは、これを次のステップの入力として使用して、顕著なソース・コード行３０８を発見するステップ３０６に進む。これは、抽象化レベルＡＬ２０４に応じて、すなわち顕著なソース・コード行３０８が１つ、２つ、３つ、またはそれ以上の並列実行スレッドで発見され得るかに応じて実行される。

【0092】

次のステップでは、式（１）に従って抽象化率および範囲推奨が決定される（３１０）。単一の受信されたコア・ダンプの場合、出力３１２は、顕著なソース・コード行２１８、抽象化率２２０、および関連する範囲２２２の形式で生成される。

【0093】

次いで、抽象化率が範囲内にあるかどうかが判定される（３１４）。範囲内にない場合、すなわち「Ｎ」の場合、プロセスは、抽象化レベルを変更するステップ３１６に進み、コア・ダンプを分析するステップ３０２に戻る。

【0094】

一方、抽象化率値が範囲内にあると判定された場合（３１４）、プロセスは、通常の根本原因分析を続行する（３１８）。

【0095】

図４は、複数のコア・ダンプ・ファイルを考慮した、拡張された実施形態４００のブロック図を示す。プロセスは、複数のコア・ダンプ・ファイル２０２および抽象化レベル２０４から開始する。最初に、すべてのコア・ダンプ・ファイルの順列を含むグループが決定される（４０２）。次いで、コア・ダンプ・ファイル２０２の順列ごとに、ユーザとの対話なしで図１による方法が実行される（４０４）。結果として得られたＡＲ値に基づいて、順列が並べ替えられ（４０６）、順列の最良のＡＲを有する結果がユーザ、例えば分析者／プログラマに表示（または、さもなければ出力）される（４０８）。ユーザは、自身の根本原因分析を実行し、根本原因ヒットＲＣＨ（「１」）またはミス（「０」）を入力（受信）してもよい（４１０）。

【0096】

判定４１２において、ＲＣＨ値が１である、つまり根本原因分析が成功したことに等しい場合、プロセスは終了する（４１４）。それ以外の場合、順列の次善の結果が表示され（４１６）、手順が繰り返される。

【0097】

最後になるが、図５は、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするための本発明のコア・ダンプ分析システム５００の実施形態のブロック図を示す。システム５００は、プロセッサ５０４に通信可能に結合されたメモリ５０２を含み、メモリは、プロセッサによって実行されたときに、具体的には受信機ユニット５０６によって、複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、具体的には識別ユニット５０８によって、ソフトウェア・クラッシュ時に実行中スレッドごとに、少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、具体的には第１の決定ユニットによって、事前定義された抽象化レベル値に応じて固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップとをプロセッサが実行することを可能にするプログラム・コード部分を記憶する。抽象化レベルの値は、異なるスレッド内での顕著なソース・コード行の発生回数を示す。

【0098】

さらに、ソース・コード分析システム５００のプログラム・コード部分は、具体的には第２の決定ユニットによって、顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率を決定するステップと、具体的には評価モジュール５１４によって、固有ソース・コード行を顕著なソース・コード行として決定するステップおよび抽象化率を決定するステップのさらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、具体的にはコンピュータＩ／Ｏシステム５１６によって、顕著なソース・コード行および抽象化率の値の評価値を出力するステップとをプロセッサが実行することを可能にする。

【0099】

すべての機能ユニット、モジュール、および機能ブロック、すなわち、５０４のプロセス、メモリ５０２、受信機ユニット５０６、識別ユニット５０８、第１の決定ユニット５１０、第２の決定ユニット５１２、評価モジュール５１４、およびＩ／Ｏシステム５１６は、選択された１：１方式での信号交換またはメッセージ交換のために互いに通信可能に結合されてもよいことにも言及される。代替として、機能ユニット、モジュール、および機能ブロックは、おそらく選択的な信号交換またはメッセージ交換のために、システム内部バス・システム５１８にリンクされ得る。

【0100】

本発明の実施形態は、プラットフォームがプログラム・コードの記憶もしくは実行またはその両方に好適であるかに関係なく、事実上、任意のタイプのコンピュータと共に実装されてもよい。図６は、一例として、提案された方法に関連するプログラム・コードを実行するのに好適なコンピューティング・システム６００を示す。

【0101】

コンピューティング・システム６００は、好適なコンピュータ・システムの一例にすぎず、コンピュータ・システム６００が上記の機能のいずれかを実装すること、もしくは実行すること、またはその両方が可能であるかどうかに関係なく、本明細書で説明される本発明の実施形態の使用または機能の範囲に関していかなる制限も示唆することを意図したものではない。コンピュータ・システム６００には、他の多数の汎用もしくは専用のコンピューティング・システム環境またはコンピューティング・システム構成で動作する構成要素が存在する。コンピュータ・システム／サーバ６００での使用に好適であり得るよく知られたコンピューティング・システム、コンピューティング環境、もしくはコンピューティング構成またはそれらの組合せの例には、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルド・デバイスまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベースのシステム、セット・トップ・ボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムまたはデバイスのいずれかを含む分散型クラウド・コンピューティング環境などが含まれるが、これらに限定されない。コンピュータ・システム／サーバ６００は、コンピュータ・システム６００によって実行されるプログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で説明され得る。一般に、プログラム・モジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、構成要素、ロジック、データ構造などが含まれ得る。コンピュータ・システム／サーバ６００は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境において実践されてもよい。分散型クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカル・コンピュータ・システム記憶媒体とリモート・コンピュータ・システム記憶媒体との両方に配置されてもよい。

【0102】

図に示すように、コンピュータ・システム／サーバ６００は、汎用コンピューティング・デバイスの形式で示されている。コンピュータ・システム／サーバ６００の構成要素は、１つもしくは複数のプロセッサまたは処理ユニット６０２と、システム・メモリ６０４と、システム・メモリ６０４を含む様々なシステム構成要素をプロセッサ６０２に結合するバス６０６とを含み得るが、これらに限定されない。バス６０６は、メモリ・バスまたはメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、および様々なバス・アーキテクチャのいずれかを使用するプロセッサまたはローカル・バスを含む、任意のいくつかのタイプのバス構造のうちの１つまたは複数を表す。限定ではなく例として、そのようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）ローカル・バス、および周辺構成要素相互接続（ＰＣＩ）バスを含む。コンピュータ・システム／サーバ６００は、典型的には、様々なコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ６００によってアクセス可能な任意の利用可能な媒体であってよく、揮発性媒体と不揮発性媒体との両方、取り外し可能な媒体と取り外し不可能な媒体との両方を含む。

【0103】

システム・メモリ６０４は、ランダム・アクセス・メモリ（ＲＡＭ）６０８もしくはキャッシュ・メモリ６１０またはその両方などの揮発性メモリの形式のコンピュータ・システム可読媒体を含んでもよい。コンピュータ・システム／サーバ６００は、取り外し可能／取り外し不可能な、揮発性／不揮発性の他のコンピュータ・システム記憶媒体をさらに含んでもよい。単なる例として、取り外し不可能な不揮発性磁気媒体（図示せず、典型的には「ハード・ドライブ」と呼ばれる）からの読出しおよびその媒体への書込みのために、ストレージ・システム６１２が設けられてもよい。図示していないが、取り外し可能な不揮発性磁気ディスク（例えば「フロッピ（登録商標）・ディスク」）からの読出しおよびそのディスクへの書込みのための磁気ディスク・ドライブと、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、もしくは他の光学媒体などの取り外し可能な不揮発性光ディスクからの読出しまたはそのディスクへの書込みのための光ディスク・ドライブとが設けられてもよい。そのような場合、それぞれは、１つまたは複数のデータ媒体インターフェースによってバス６０６に接続され得る。以下にさらに図示および説明するように、メモリ６０４は、本発明の実施形態の機能を実施するように構成されたプログラム・モジュールのセット（例えば、そのうちの少なくとも１つ）を有する少なくとも１つのプログラム製品を含んでもよい。

【0104】

プログラム・モジュール６１６のセット（そのうちの少なくとも１つ）を有するプログラム／ユーティリティは、限定ではなく例として、メモリ６０４に記憶されてもよく、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データも同様である。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ、またはそれらのいくつかの組合せはそれぞれ、ネットワーキング環境の実装を含んでもよい。プログラム・モジュール６１６は一般に、本明細書で説明されたように、本発明の実施形態の機能もしくは方法論またはその両方を実施する。

【0105】

コンピュータ・システム／サーバ６００はまた、キーボード、ポインティング・デバイス、ディスプレイ６２０などの１つもしくは複数の外部デバイス６１８、ユーザがコンピュータ・システム／サーバ６００と対話することを可能にする１つもしくは複数のデバイス、またはコンピュータ・システム／サーバ６００が１つもしくは複数の他のコンピューティング・デバイスと通信することを可能にする任意のデバイス（例えば、ネットワーク・カード、モデムなど）、またはそれらの組合せと通信してもよい。そのような通信は、入出力（Ｉ／Ｏ）インターフェース６１４を介して行われ得る。さらに、コンピュータ・システム／サーバ６００は、ネットワーク・アダプタ６２２を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、一般的なワイド・エリア・ネットワーク（ＷＡＮ）、もしくはパブリック・ネットワーク（例えば、インターネット）またはそれらの組合せなどのうちの１つまたは複数のネットワークと通信してもよい。図示されているように、ネットワーク・アダプタ６２２は、バス６０６を介してコンピュータ・システム／サーバ６００の他の構成要素と通信してもよい。図示していないが、他のハードウェア構成要素もしくはソフトウェア構成要素またはその両方がコンピュータ・システム／サーバ６００と併せて使用可能であることが理解されるべきである。例には、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが含まれるが、これらに限定されない。

【0106】

さらに、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコア・ダンプ分析システム５００が、バス・システム６０６に取り付けられてもよい。

【0107】

本発明の様々な実施形態の説明を例示の目的で提示してきたが、この説明は、網羅的であることも、開示された実施形態に限定されることも意図していない。当業者には、説明した実施形態の範囲および思想から逸脱することなく多くの修正形態および変形形態が明らかであろう。本明細書で使用される用語は、実施形態の原理、実際の適用例、もしくは市場で見られる技術を超える技術的な改良を最もよく説明するように、または本明細書で開示された実施形態を他の当業者が理解することが可能になるように選択されたものである。

【0108】

本発明は、システム、方法、もしくはコンピュータ・プログラム製品またはそれらの組合せとして具現化されてもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実施させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体（または複数のコンピュータ可読記憶媒体）を含んでもよい。

【0109】

媒体は、電子媒体、磁気媒体、光学媒体、電磁媒体、赤外線媒体、または伝播媒体用の半導体システムであってもよい。コンピュータ可読媒体の例には、半導体メモリまたはソリッド・ステート・メモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、硬質磁気ディスク、および光ディスクが含まれ得る。現在の光ディスクの例には、コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ－ＲＯＭ）、コンパクト・ディスク読出し／書込み（ＣＤ Ｒ／Ｗ）、ＤＶＤ、およびＢｌｕ－ｒａｙ（登録商標）ディスクが含まれる。

【0110】

コンピュータ可読記憶媒体は、命令実行デバイスが使用するための命令を保持および記憶することができる有形デバイスとすることができる。コンピュータ可読記憶媒体は、例えば、電子記憶デバイス、磁気記憶デバイス、光学記憶デバイス、電磁気記憶デバイス、半導体記憶デバイス、または上記の任意の好適な組合せとすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストには以下のもの、すなわち、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ－ＲＯＭ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、メモリ・スティック、フロッピ（登録商標）・ディスク、パンチカードまたは命令が記録された溝内の隆起構造体などの機械的に符号化されたデバイス、および上記の任意の好適な組合せが含まれる。本明細書で使用されるコンピュータ可読記憶媒体は、電波もしくは他の自由に伝播する電磁波、導波路もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバ・ケーブルを通る光パルス）、または電線を介して送信される電気信号などの一過性の信号自体であると解釈されるべきではない。

【0111】

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、または、ネットワーク、例えばインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくはワイヤレス・ネットワーク、またはそれらの組合せを介して、外部コンピュータまたは外部記憶デバイスにダウンロードされ得る。ネットワークは、銅伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバ、またはそれらの組合せを含んでもよい。各コンピューティング／処理デバイスにおけるネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、そのコンピュータ可読プログラム命令を、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶するために転送する。

【0112】

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、インストラクション・セット・アーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、または、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋などのオブジェクト指向プログラミング言語およびＣプログラミング言語もしくは同様のプログラミング言語などの従来の手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組合せで記述されたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、全体がユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして一部がユーザのコンピュータ上で、一部がユーザのコンピュータ上かつ一部がリモート・コンピュータ上で、または全体がリモート・コンピュータ上もしくはサーバ上で実行されてもよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよく、または（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して接続されてもよい。いくつかの実施形態では、本発明の態様を実行するために、例えば、プログラマブル・ロジック回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む電子回路が、コンピュータ可読プログラム命令の状態情報を利用して電子回路をパーソナライズすることによって、コンピュータ可読プログラム命令を実行してもよい。

【0113】

本明細書では、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照しながら、本発明の態様について説明している。フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方におけるブロックの組合せがコンピュータ可読プログラム命令によって実施され得ることが理解されよう。

【0114】

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサを介して実行される命令が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックで指定された機能／作用を実施するための手段を作り出すように、汎用コンピュータ、専用コンピュータ、または他のプログラマブル・データ処理装置のプロセッサに提供されて、マシンを作り出すものであってもよい。これらのコンピュータ可読プログラム命令はまた、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックで指定された機能／作用の態様を実施する命令を含む製造品を含むように、コンピュータ可読媒体に記憶され、コンピュータ、プログラマブル・データ処理装置、もしくは他のデバイスまたはそれらの組合せが特定の方式で機能するように指示できるものであってもよい。

【0115】

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラマブル装置、または別のデバイスで実行される命令が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックで指定された機能／作用を実施するように、コンピュータ実施プロセスを作り出すべくコンピュータ、他のプログラマブル・データ処理装置、または他のデバイスにロードされて、コンピュータ、他のプログラマブル装置、または別のデバイス上で一連の動作ステップを実行させるものであってもよい。

【0116】

図中のフローチャートもしくはブロック図またはその両方は、本発明の様々な実施形態によるシステム、方法およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能性、ならびに動作を示す。これに関して、フローチャートまたはブロック図における各ブロックは、指定された論理機能を実装するための１つまたは複数の実行可能命令を含む、命令のモジュール、セグメント、または一部を表すことがある。いくつかの代替の実装形態では、ブロックに記載された機能は、図に記載された順序とは異なる順序で行われてもよい。例えば、連続して示されている２つのブロックは、実際には、関与する機能性に応じて、実質的に同時に実行されてもよく、またはそれらのブロックは、場合によっては逆の順序で実行されてもよい。ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方におけるブロックの組合せは、指定された機能もしくは作用を実行するか、または専用ハードウェアとコンピュータ命令との組合せを遂行する専用ハードウェア・ベースのシステムによって実装され得ることにも留意されたい。

【0117】

本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、本発明を限定することを意図するものではない。単数形ａ、ａｎ、およびｔｈｅは、本明細書で使用される場合、文脈上特に明記されていない限り、複数形も含むことを意図している。備える（comprises）もしくは備える（comprising）という用語またはその両方は、本明細書で使用される場合、記載された特徴、整数、ステップ、動作、要素、もしくは構成要素またはそれらの組合せの存在を示すが、１つもしくは複数の他の特徴、整数、ステップ、動作、要素、構成要素、またはこれらのグループ、またはそれらの組合せの存在もしくは追加を除外するものではないことがさらに理解されよう。

【0118】

添付の特許請求の範囲内のすべての手段またはステップならびに機能要素の対応する構造、材料、作用、および均等物は、具体的に特許請求されるように、他の特許請求される要素と組み合わせて機能を実行するための任意の構造、材料、または作用を含むことが意図されている。本発明の説明は、例示および説明の目的で提示されているが、網羅的であること、または開示された形式の本発明に限定されることを意図したものではない。本発明の範囲および思想から逸脱することなく、多くの修正形態および変形形態が当業者には明らかであろう。実施形態は、本発明の原理および実際の適用例を最も適切に説明するために、および企図される特定の用途に適するように様々な修正を加えた様々な実施形態について他の当業者が本発明を理解できるようにするために、選択および説明されている。

【0119】

簡潔に言えば、本発明の概念は、次の条項によって要約され得る。

【0120】

１．コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコンピュータ実装方法であって、
－複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－ソフトウェア・クラッシュ時に実行中スレッドごとに、少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、抽象化レベル値が、異なるスレッド内での顕著なソース・コード行の発生回数を示す、決定するステップと、
－顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率の値を決定するステップと、
－固有ソース・コード行を顕著なソース・コード行として決定するステップおよび抽象化率の値を決定するステップのさらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－顕著なソース・コード行および抽象化率の値の評価値を出力するステップと
を含む、コンピュータ実装方法。

【0121】

２．出力される顕著なソース・コード行が、クラッシュ時に実行中スレッド内での出現頻度によって順序付けされる、条項１に記載の方法。

【0122】

３．固有ソース・コード行を識別するステップが、
－所与のクラッシュの根本原因分析に十分である可能性が高いスレッドの部分集合を選択すること
をさらに含む、条項１または２に記載の方法。

【0123】

４．事前定義された抽象化レベルが、顕著なソース・コード行の決定がどの程度の細粒度で行われるかを示す、条項１ないし３のいずれかに記載の方法。

【0124】

５．
－抽象化率の値の評価値が事前定義された範囲内にあるかどうかを判定するステップ
も含む、条項１ないし４のいずれかに記載の方法。

【0125】

６．
－方法の実行に基づいて根本原因分析が成功したかどうかを示す根本原因ヒット値、
－抽象化率の関連する値、もしくは
－抽象化率の値の可能な値の全範囲のバケット・サイズ値に依存する、関連するバケット・インデックス、またはそれらの組合せ
を永続的に記憶するステップも含む、条項１ないし５のいずれかに記載の方法。

【0126】

７．
－抽象化率の下限閾値もしくは上限閾値またはその両方を決定するステップであって、下限閾値および上限閾値が、根本原因分析が成功する確率が高いことを表す抽象化率の値に関する範囲を定義する、決定するステップ
も含む、条項６に記載の方法。

【0127】

８．
－グループの他のコア・ダンプ・ファイルに適合しない少なくとも２つのコア・ダンプ・ファイルを含むグループからコア・ダンプ・ファイルを選択解除するステップ
も含む、条項１ないし７のいずれかに記載の方法。

【0128】

９．少なくとも１つのコア・ダンプ・ファイルを受信するステップが、
－少なくとも１つのコア・ダンプ・ファイルを人間が読める文字に変換すること
も含む、条項１ないし８のいずれかに記載の方法。

【0129】

１０．方法が、少なくとも１つのコア・ダンプ・ファイルが作成される前にソフトウェア・プログラムが実行されたハードウェア・アーキテクチャに依存しない、条項１ないし９のいずれかに記載の方法。

【0130】

１１．
－受信した少なくとも１つのコア・ダンプ・ファイルの可能な組合せをコア・ダンプ・ファイルとして構築するステップと、
－（ｉ）固有ソース・コード行を識別するステップ、（ｉｉ）固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップ、（ｉｉｉ）抽象化率を決定するステップ、および（ｉｖ）さらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップ、を実行するステップと、
－最も高い抽象化率に関連する出力すべきこれらの顕著なソース・コード行を選択するステップと
も含む、条項１ないし１０のいずれかに記載の方法。

【0131】

１２．コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコア・ダンプ分析システムであって、システムが、
－プロセッサに通信可能に結合されたメモリを備え、メモリが、プロセッサによって実行されたときに、
－複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－ソフトウェア・クラッシュ時に実行中スレッドごとに、少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、抽象化レベル値が、異なるスレッド内での顕著なソース・コード行の発生回数を示す、決定するステップと、
－顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率の値を決定するステップと、
－固有ソース・コード行を顕著なソース・コード行として決定するステップおよび抽象化率の値を決定するステップのさらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－顕著なソース・コード行および抽象化率の値の評価値を出力するステップと
をプロセッサが実行することを可能にするプログラム・コード部分を記憶する、コア・ダンプ分析システム。

【0132】

１３．出力される顕著なソース・コード行が、クラッシュ時に実行中スレッド内での出現頻度によって順序付けされる、条項１２に記載のシステム。

【0133】

１４．プログラム・コード部分が、固有ソース・コード行を識別する間に、
－所与のクラッシュの根本原因分析に十分である可能性が高いスレッドの部分集合を選択すること
をプロセッサが実行することも可能にする、条項１２または１３に記載のシステム。

【0134】

１５．事前定義された抽象化レベルが、顕著なソース・コード行の決定がどの程度の細粒度で行われるかを示す、条項１２ないし１４のいずれかに記載のシステム。

【0135】

１６．プログラム・コード部分が、
－抽象化率の値の評価値が事前定義された範囲内にあるかどうかを判定するステップ
をプロセッサがさらに実行することを可能にする、条項１２ないし１５のいずれかに記載のシステム。

【0136】

１７．プログラム・コード部分が、
－グループから選択された少なくとも１つの値、すなわち、
－方法の実行に基づいて根本原因分析が成功したかどうかを示す根本原因ヒット値、
－関連する抽象化率値、および
－抽象化率の値の可能な値の全範囲のバケット・サイズ値に依存する、関連するバケット・インデックス
を永続的に記憶するステップをプロセッサがさらに実行することを可能にする、条項１２ないし１６のいずれかに記載のシステム。

【0137】

１８．プログラム・コード部分が
－抽象化率の下限閾値もしくは上限閾値またはその両方を決定するステップであって、下限閾値および上限閾値が、根本原因分析が成功する確率が高いことを表す抽象化率に関する範囲を定義する、決定するステップ
をプロセッサがさらに実行することを可能にする、条項１７に記載のシステム。

【0138】

１９．プログラム・コード部分が、
－グループの他のコア・ダンプ・ファイルに適合しない少なくとも２つのコア・ダンプ・ファイルを含むグループからコア・ダンプ・ファイルを選択解除するステップ
をプロセッサがさらに実行することを可能にする、条項１２ないし１８のいずれかに記載のシステム。

【0139】

２０．コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコンピュータ・プログラム製品であって、階層が、根ノードと、関連する部分木を含む少なくとも１つの子ノードとを含み、コンピュータ・プログラム製品が、プログラム命令が具現化されたコンピュータ可読記憶媒体を含み、プログラム命令が、１つまたは複数のコンピューティング・システムまたはコントローラによって実行可能であり、１つまたは複数のコンピューティング・システムに、
－複数のスレッドとして実行可能なソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－ソフトウェア・クラッシュ時に実行中スレッドごとに、少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、抽象化レベル値が、異なるスレッド内での顕著なソース・コード行の発生回数を示す、決定するステップと、
－顕著なソース・コード行の数および固有ソース・コード行の数の関数として抽象化率を決定するステップと、
－固有ソース・コード行を顕著なソース・コード行として決定するステップおよび抽象化率を決定するステップのさらなる反復のために、事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－顕著なソース・コード行および抽象化率の値の評価値を出力するステップと
を実行させる、コンピュータ・プログラム製品。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【手続補正書】

【提出日】2023-12-18

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

コンピュータの情報処理により、コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にする方法であって
－複数のスレッドとして実行されるソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－前記ソフトウェア・クラッシュ時に実行中スレッドごとに、前記少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて前記固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、前記抽象化レベル値が、異なるスレッド内での前記顕著なソース・コード行の発生回数を示す、前記決定するステップと、
－顕著なソース・コード行の数および前記固有ソース・コード行の数の関数として抽象化率の値を決定するステップと、
－前記固有ソース・コード行を前記顕著なソース・コード行として決定する前記ステップおよび前記抽象化率の前記値を決定する前記ステップのさらなる反復のために、前記事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－前記顕著なソース・コード行および前記抽象化率の前記値の評価値を出力するステップと
を含む、方法。

【請求項2】

出力される前記顕著なソース・コード行は、前記クラッシュ時に実行中スレッド内での出現頻度によって順序付けされる、請求項１に記載の方法。

【請求項3】

前記固有ソース・コード行を識別するステップは、
－所与のクラッシュの根本原因分析に十分である可能性が高いスレッドの部分集合を選択すること
をさらに含む、請求項１に記載の方法。

【請求項4】

前記事前定義された抽象化レベルは、前記顕著なソース・コード行の前記決定がどの程度の細粒度で行われるかを示す、請求項１に記載の方法。

【請求項5】

－前記抽象化率の前記値の前記評価値が事前定義された範囲内にあるかどうかを判定するステップ
も含む、請求項１に記載の方法。

【請求項6】

－前記方法の実行に基づいて根本原因分析が成功したかどうかを示す根本原因ヒット値、
－前記抽象化率の関連する値、もしくは
－前記抽象化率の前記値の可能な値の全範囲のバケット・サイズ値に依存する、関連するバケット・インデックス、
またはそれらの組合せを永続的に記憶するステップも含む、請求項１に記載の方法。

【請求項7】

－前記抽象化率の下限閾値もしくは上限閾値またはその両方を決定するステップであって、前記下限閾値および前記上限閾値が、根本原因分析が成功する確率が高いことを表す前記抽象化率の前記値に関する範囲を定義する、前記決定するステップ
も含む、請求項６に記載の方法。

【請求項8】

－グループの他のコア・ダンプ・ファイルに適合しない少なくとも２つのコア・ダンプ・ファイルを含む前記グループからコア・ダンプ・ファイルを選択解除するステップ
も含む、請求項１に記載の方法。

【請求項9】

前記少なくとも１つのコア・ダンプ・ファイルを受信する前記ステップは、
－前記少なくとも１つのコア・ダンプ・ファイルを人間が読める文字に変換すること
も含む、請求項１に記載の方法。

【請求項10】

前記方法は、前記少なくとも１つのコア・ダンプ・ファイルが作成される前に前記ソフトウェア・プログラムが実行されたハードウェア・アーキテクチャに依存しない、請求項１に記載の方法。

【請求項11】

－前記受信した少なくとも１つのコア・ダンプ・ファイルの可能な組合せをコア・ダンプ・ファイルとして構築するステップと、
－（ｉ）前記固有ソース・コード行を識別する前記ステップ、（ｉｉ）前記固有ソース・コード行のそれぞれを前記顕著なソース・コード行として決定する前記ステップ、（ｉｉｉ）前記抽象化率を決定する前記ステップ、および（ｉｖ）前記さらなる反復のために、前記事前定義された抽象化レベル値を調整する必要があるかどうかを評価する前記ステップ、を実行するステップと、
－最も高い抽象化率に関連する出力すべきこれらの顕著なソース・コード行を選択するステップと
も含む、請求項１に記載の方法。

【請求項12】

コア・ダンプ分析によるソフトウェア・クラッシュの根本原因分析を容易にするためのコア・ダンプ分析システムであって、前記システムが、
－プロセッサに通信するように結合されたメモリを備え、前記メモリが、前記プロセッサによって実行されたときに、
－複数のスレッドとして実行されるソフトウェア・プログラムに関連する少なくとも１つのコア・ダンプ・ファイルを受信するステップと、
－前記ソフトウェア・クラッシュ時に実行中スレッドごとに、前記少なくとも１つのコア・ダンプ・ファイル内の固有ソース・コード行を識別するステップと、
－事前定義された抽象化レベル値に応じて前記固有ソース・コード行のそれぞれを顕著なソース・コード行として決定するステップであって、前記抽象化レベル値が、異なるスレッド内での前記顕著なソース・コード行の発生回数を示す、前記決定するステップと、
－顕著なソース・コード行の数および前記固有ソース・コード行の数の関数として抽象化率の値を決定するステップと、
－固有ソース・コード行を前記顕著なソース・コード行として決定する前記ステップおよび前記抽象化率の前記値を決定する前記ステップのさらなる反復のために、前記事前定義された抽象化レベル値を調整する必要があるかどうかを評価するステップと、
－前記顕著なソース・コード行および前記抽象化率の前記値の評価値を出力するステップと
を前記プロセッサに実行させるプログラム・コード部分を記憶する、コア・ダンプ分析システム。

【請求項13】

請求項１～１１のいずれか１項に記載された方法を、コンピュータに対して実行させるためのコンピュータ・プログラム。

【請求項14】

請求項１３に記載のコンピュータ・プログラムを記録した、コンピュータ可読記憶媒体。

【国際調査報告】