最近分割して、ローカルソケットを介して相互に通信する個別のプロセスで実行するアプリケーションがあります。コアの「ウォッチャー」プロセスが障害を検出し、問題のあるサブプロセスを再開できるため、安定性を高めるために分割しました。
しかし、今では私のウォッチャープロセスが頻繁にクラッシュし、「SegmentationFault」というメッセージだけが表示されます。すべてのスレッド化された操作をtry/catchブロックで囲み、出力をダンプしようとしましたが、それでも同じ結果が得られます。
デバッガーをMonoDevelopで動作させることができませんでした（したがって、これらのゴーストの問題がなければ開発は十分に困難でした）。
このような問題を防ぐために、Monoは管理された環境にあるべきではありませんか？問題の原因を絞り込む方法はありますか？
セグメンテーション違反は、（1）gdbを使用してデバッグする必要があります。gdbを使用してmonoをデバッグするには、最初にこれを読む必要があります。
それが完了したら、プログラムを起動し、実行ps auxfしてプログラムのpidを見つけてから、次のコマンドを実行します。
gdb program PID
これにより、gdbがプログラムにアタッチされます。gdbプロンプトが表示されます。
$ (gdb)
以下を実行します（これまでに読んだはずのリンクから）：
$ (gdb) handle SIGXCPU SIG33 SIG35 SIGPWR nostop noprint
$ (gdb) continue
プログラムが応答しなくなるまで待ちます。その場合は、gdbに戻ると、プログラムがセグメンテーション違反（SIGSEGV）で停止していることがわかり、クラッシュに関する詳細情報を取得できるはずです。特にこれは便利です：
$ (gdb) thread apply all backtrace
これにより、すべてのスレッドのスタックトレースが表示されます。
（1）Console.WriteLineの呼び出しを使用して、コードを散りばめるより野蛮な方法を使用することもできます。これは、他のすべてが失敗したときの最後の手段です:)
モノは管理された環境であり、それはあなたの質問を私に本当に独特なものにします。どのような状況で、実際にセグメンテーション違反を引き起こす方法でメモリを処理していますか？コードのマークされた部分はありますunsafeか？もしそうなら、私は最初にそこを見るでしょう。それ以外の場合は、すでに実行中のプロセスにデバッガーを接続する方法があります。Monodevelopからデバッグしていない場合は、これを実行しようとします。
考えれば考えるほど、自分でメモリ操作を行わない場合は、コードにセグメンテーション違反が発生することはありません。それはおそらく実行時にあり、もしそうなら、try/catchesはあなたを助けるつもりはありません。
私の提案は、テキストやコンソールロギングをうまく利用して、何が起こっているのかを1行ずつ詳細に確認することです。または、ビジュアルスタジオに飛び乗って、いくつかのトレースを実行します。
まあ、それは私のソケットのスレッドで何かだったに違いありません。自分でスレッドを処理する代わりに、Begin / End関数を使用するように切り替えたところ、問題が修正されました。