私はクライアントのSolaris SPARCシステムでコアファイルを作成するときに奇妙な動作を識別するためにしばらく作業してきました。現在のSolarisバージョンは11.4-11.4.44.0.1.113.4です。アプリケーションはGCC 11.2と-gを使用して構築されました。アプリケーションとコアファイルはGDB 10.2とpstackを使用してデバッグされます。
私は顧客にこの問題を分析して診断するのに役立つ特別なツールを提供します。アプリケーションが行うことは、分割エラーのためにコアファイルを生成することです。
問題：クライアントシステムで生成されたコアファイルは、GDBを使用してスタック、変数、またはメモリ情報を表示しません。しかし、私の開発システムでコアファイルを生成するためにまったく同じ実行ファイルを使用すると、デバッグできるコアファイルが生成されます。
最初は、これがSolaris 11.4パッチの非互換性と関連している可能性があると思いました。クライアントから取得したコアファイルセットに対して、11.4.39から11.4.47までのすべてのSolarisパッチレベルを試しましたが、大きな違いはありませんでした。
たとえば、開発システムでは、コアファイルはGDBで生成されます。
。 。 。
core_dump_tool.exeからシンボルを読む...
[新規LWP 1]
[libthread_dbを使用したスレッドデバッグの有効化]
[新しいスレッド1（LWP 1）]
コアは「./core_dump_tool.exe」によって生成されます。
プログラムはSIGSEGV信号（セグメントエラー）で終了しました。
/usr/lib/libc.so.1 の _malloc_unlocked() の #0 0xfe3cdc80
【現在スレッドは1（LWP 1）】
(gdb)どこに
/usr/lib/libc.so.1 の _malloc_unlocked() の #0 0xfe3cdc80
#1 /usr/lib/libc.so.1 の do_malloc() にある 0xfe3cd9d4
#2 core_dump_tool.c:82 のバッファオーバーフロー (iDataLength=100, cpData=0xffbff140 12 34567890123456789") の 0x00011a40
#3 core_dump_tool.c:232のmain()の0x00011f80
バックトラッキング停止：このフレーム内の前のフレーム（スタック破損？）
(gdb) 終了
。 。 。
まったく同じアプリケーションがクライアントシステムで実行されると、結果のコアファイルはGDBにこのファイルを生成します。
。 。 。
core_dump_tool.exeからシンボルを読む...
[新規LWP 1]
[libthread_dbを使用したスレッドデバッグの有効化]
[新しいスレッド1（LWP 1）]
コアは "core_dump_tool.exe" によって生成されます。
プログラムはSIGSEGV信号（セグメントエラー）で終了しました。
/usr/lib/libc.so.1 の _malloc_unlocked() の #0 0xfeb6daf0
（gdb）BT
/usr/lib/libc.so.1 の _malloc_unlocked() の #0 0xfeb6daf0
#1 0x00022514??()
バックトラッキング停止：前のフレームはこのフレームと同じです（スタック破損？）
(gdb) 終了
。 。 。
お客様のシステムとシステムで生成されたコアファイルに関する質問です。
- この問題は2021年12月に初めて登場しました。 2021年9月から2021年12月初めまでにコアファイルの問題を絞り込むことができました。
- 顧客はこの期間の間に生産機械にどんな変更があったか全く知りません。記録が見つからず、管理者は去った。
- クライアントから影響を受けるシステムのcoreadmおよびdumpadm構成を要求しましたが、まだ情報を受信していません。
お客様がコアファイルを生成するシステムに及ぼす影響について考えや考えがある方がいらっしゃいます。
ベストアンサー1
お客様のクライアントは、問題のシステムでコアファイルのサイズが制限されている可能性があります。
Solaris はスタック情報をコアファイルに書き込みます。最後したがって、コアファイルサイズにリソース制約がある場合、スタック情報はコアファイルに書き込まれません。そして、コアファイルはデバッグに事実上役に立たない。
Solarisには2つの便利なコアファイルサイズ制限設定があります。 0コアファイルが生成されないようにすることで、結果のunlimitedコアファイルが実際に効果がある。
また、設定に関する注意事項 - コアファイル名からプロセス名、PID、時間などのデータをキャプチャしたり、より多くを保存したりするなどのタスクを実行するために、プロセスの現在の作業ディレクトリでデフォルトのコアcoreadmファイルモードを変更した場合core最後のコアファイルよりも、coreまたはグローバルコアファイル設定を使用して、すべてのコアファイルを共通の場所にキャプチャします。これで、コアファイルが記憶領域をいっぱいにする前に事前に管理する必要があります。。
重要なシステムのプロセスが高速フェールオーバー状態になり、毎回新しいコアファイルが作成されるとどうなりますか？ディスクがいっぱいになってシステムがクラッシュするのは、coreadmすべてのコアファイルを保存するコアファイル名パターンを設定したためです。
こんな。
お客様に、すべてのコアファイルを保存するためにコアファイル名パターンを設定するように指示したり、それを実行するように独自のシステムを構成するように指示しないでください。その場合は、システムがコアファイルを積極的に管理する必要があることを教えてください。
「コアファイルを事前に管理する」とは、「毎日cronジョブを実行する」という意味ではありません。何をしても、毎分500のコアファイルを生成する暴走プロセスを処理できるはずです。
または、少なくともシステムリポジトリの残りの部分を埋めることができない専用ファイルシステムで作成されたグローバルコアファイルを使用するように指示して、その専用コアファイルコレクションファイルシステムがいっぱいであっても残りの部分に損傷を与えないようにしてください。システムは体系的です。