Python、Java、およびC++を混在させることで作成されたプロセスは、時々コアダンプを実行します。実行時に必要に応じてより多くのメモリをチャンクとして割り当て、割り当てが4Gを超えると競合が発生します（malloc()戻り値は確認されません）。
しかし、GDBによると、結果のコアダンプは切り捨てられます。オペレーティングシステムのサイズに制限はなく、ディスクのサイズは2〜3.8Gです。
GDBはサイズが予想されたものと異なることを観察し（おそらく失敗した割り当てを含めますか？）、放棄します。しかし、それは確かに3.8Gデータにあります。何興味がありませんか？たぶんスタック全体を逆追跡する必要があるかもしれません！
GDBが少なくとも試すように説得できますか？それとも、切り捨てられたコアから何かを抽出するための代替ツールはありますか？
ベストアンサー1
Sun Studio 12 Webサイトのこの広告テキストは、基本的に役に立たないことを示唆しているようです。
抜粋http://docs.oracle.com/cd/E19205-01/819-5257/blabs/index.htmlコアファイルが切り捨てられた場合
コアファイルの読み込みに問題がある場合は、コアファイルが切り捨てられていることを確認してください。コアファイルの作成時に許容される最大コアファイルサイズが低すぎると、dbxは切り捨てられた結果コアファイルを読み取ることができません。 Cシェルでは、制限コマンドを使用して最大許容コアファイルサイズを設定できます（limit（1）のマニュアルページを参照）。 Bourne シェルと Korn シェルでは ulimit コマンドを使用します (limit(1) のマニュアルページを参照)。シェルの起動ファイルでコアファイルのサイズ制限を変更し、起動ファイルを再起動してから、コアファイルを生成したプログラムを再度実行してコアファイル全体を生成できます。
コアファイルが不完全でスタックセグメントが欠落している場合、スタックトレース情報は利用できません。ランタイムリンカー情報が失われると、ロードオブジェクトリストは使用できません。このシナリオでは、librtld_db.so が初期化されていないというエラー メッセージが表示されます。 LWP リストがない場合、スレッド情報、lwp 情報、またはスタックトレース情報は使用できません。 whereコマンドを実行すると、プログラムが「アクティブ」ではないというエラーメッセージが表示されます。