2

ときどき Go プログラムがクラッシュします。

このプログラムのコア ダンプを生成するために、いくつかのことを試しました。

  1. システムでulimitを定義して、念のため両方を試しulimit -c unlimitedましulimit -c 10000た。パニック プログラムを起動した後、コア ダンプが表示されません。

  2. またrecover()、プログラムにサポートを追加し、パニックの場合に syslog にログを記録するコードを追加しましたが、syslog には何も記録されません。

私は今、アイデアが不足しています。

私は何かを見落としていたに違いありませんが、何かが見つかりません。助けていただければ幸いです。

ありがとう ！:)

4

2 に答える 2

4

特定のセットの条件が満たされると、OS によってコア ダンプが生成されることに注意してください。これらの条件は、マップされていないメモリにアクセスしようとしたり、CPU が認識していないオペコードを実行しようとしたりするなど、非常に低レベルです。Linux などの POSIX オペレーティング システムでは、プロセスがこれらのいずれかを実行すると、適切なシグナルがそれ、およびそれらのいくつかは、プロセスによって処理されない場合、コアダンプを生成するデフォルトのアクションを持ちます。これは、特定の制限を設定することによって禁止されていない場合、OS によって行われます。

この機械は可能な限り低いレベル (マシンコード) でプロセスを処理しますが、Go コンパイラが生成するバイナリは、C コンパイラ (またはアセンブラ) が生成するバイナリよりも高レベルであり、これは生成されたプロセスで特定のエラーが発生することを意味します。 Go コンパイラによる処理は、OS ではなく Go ランタイムによって処理されます。たとえば、C コンパイラによって生成されたプロセスでの典型的な NULL ポインターの逆参照は、通常、プロセスに SIGSEGV シグナルを送信することになり、通常、プロセスのコアをダンプして終了しようとします。対照的に、Go コンパイラによってコンパイルされたプロセスでこれが発生すると、Go ランタイムが起動してパニックになり、デバッグ用の適切なスタック トレースが生成されます。

これらの事実を念頭に置いて、私はこれをやろうとします：

  1. 最初にコア ダンプの制限を緩和し (ただし、以下を参照)、標準エラー ストリームをファイルにリダイレクト (またはloggerバイナリなどにパイプ) してプログラムを実行するシェル スクリプトでプログラムをラップします。
  2. ユーザーが微調整できる制限には階層があります。ソフト制限とハード制限があります。説明については、これとこれを参照してください。システムのコア ダンプ サイズがハード リミットとして 0 に設定されていないことを確認してください。
  3. 少なくとも私の Debian システムでは、SIGSEGV が原因でプログラムが停止した場合、この事実はカーネルによってログに記録され、syslog ログ ファイルに表示されるため、ヒントを得るためにそれらを grep してみてください。
于 2013-02-19T07:47:12.443 に答える
0

  1. まず、すべてのエラーが処理されていることを確認してください。

  2. コア ダンプについては、linux でコア ダンプを生成するを参照してください。

  3. スーパーバイザーを使用して、プログラムがクラッシュしたときにプログラムを再起動できます。

于 2013-02-19T01:32:29.847 に答える