gdb対話モードで単純なプログラムを実行しているときに、セグメンテーション違反を見つけるために使用するのは非常に簡単です。しかし、(コマンドpthreadによって) クラスター ノードにサブミットされたマルチスレッド プログラム (作成者) があるとします。qsubしたがって、インタラクティブな操作はありません。
セグメンテーション違反を特定するにはどうすればよいでしょうか? 一般的なアプローチ、プログラムまたはテスト ツールを探しています。プログラムは非常に大きく、未知の状況でクラスターでクラッシュするため、再現可能な例を提供することはできません。
プログラムはローカル マシン上で任意の数のスレッドで正しく実行されるため、このような困難な状況で問題を見つける必要があります。
「通常の」アプローチは、環境にコアファイルを生成させ、それらを取得させることです。これがオプションでない場合は、SIGSEGV少なくともどこかにダンプされたスタックトレースを取得するシグナルハンドラーをインストールしてみてください。もちろん、これはすぐに「スタックトレースを取得する方法」という質問につながりますが、これは他の場所で答えられます。
最も簡単なアプローチは、おそらくコアファイルを入手することです。コアファイルを読み取ることができる同様のマシンがあると仮定すると、コアファイルを生成しgdb program corefileたプログラムをデバッグするために使用できます。さまざまなスレッド、それらのデータ（ある程度）などを確認できるはずです。適切なマシンがない場合は、実行されたマシンのハードウェアに合わせてクロスコンパイルする必要があります。programcorefilegdb
コアファイルが空であるというステートメントについて少し混乱していulimitます。シェルでを使用してコアファイルの制限を設定できます。コアのサイズがゼロに設定されている場合、コアファイルは生成されません。空のものを作るのは奇妙に思えます。ただし、プログラムの制限を変更できない場合は、シグナルハンドラーをインストールし、問題のあるスレッドからスタックトレースをダンプする必要があります。
そのことを考えると、対応するマシンでデバッガーを実行できると仮定すると、プログラムをシグナルハンドラーでスリープ状態にし、デバッガーを使用してプログラムにアタッチできる可能性があります。プロセスIDを（たとえばを使用してps -elf | grep program）決定し、次にを使用してそれに接続します
gdb program pid
ただし、プログラム内からプログラムをスリープ状態にする方法がわかりません（おそらく...のハンドラーをインストールSIGSTOPしSIGSEGVます）。
そうは言っても、ローカルマシンでプログラムを実行してみたと思います...？いくつかの問題は、各ノードで実行されている多くのスレッドの分散システムを必要とするよりも根本的なものです。これは明らかに、上記のアプローチに代わるものではありません。