スタックオーバーフローの点を検出する方法

Question

私は私のCプログラムでは、次の問題を抱えている：どこかには、スタックオーバーフローです。最適化せずに、デバッガのシンボルでコンパイルするにもかかわらず、プログラムが（内またはLinux上でGDBの外で）この出力で終了します：

信号SIGSEGV、セグメンテーションフォールトで終了プログラム。 プログラムは存在しません。 私はこの実際にスタックされるオーバーフローはvalgrindのを介して、プログラムを実行していたことを検出することができます。

唯一の方法。私は何とか私は、問題を見つけやすくなり、コールスタックトレースをダンプするために、オペレーティング・システムを強制することができます任意の方法はありますか？

悲しいことに、GDBは私が簡単にどちらかのプログラムを活用することはできません。

Answer 1

あなたは、システムがコアファイルをダンプすることができた場合は、GDBでそれらを分析することができます：

$ ulimit -c unlimited # bash sentence to allow for infinite sized cores
$ ./stack_overflow
Segmentation fault (core dumped)
$ gdb -c core stack_overflow
gdb> bt
#0  0x0000000000400570 in f ()
#1  0x0000000000400570 in f ()
#2  0x0000000000400570 in f ()
...

いくつかの回は、私が間違ってスタックトレースを持っていたひどく生成されたコアファイルを見てきましたが、ほとんどの場合、BTが同じメソッドへの再帰呼び出しの束を得られます。

コアファイルは、プロセスIDを含めることができます別の名前を持っているかもしれませんが、それは（rootまたはsudoを使用して実行）現在のシステムでは、カーネルのデフォルトの設定に依存しますが、で制御することができます：

$ sysctl kernel.core_uses_pid=1

Answer 2

GCCを使用すると、これを試すことができます：

  

-fstack-protector
      このような攻撃をスタックスマッシングとしてバッファオーバーフロー、チェックするために余分なコードを発します。これは、脆弱なオブジェクトと関数にガード変数を追加することによって行われます。これは8バイトを超えるバッファではallocaを呼び出す関数、および関数が含まれています。警備員は、関数が入力されたときに初期化され、関数が終了したときに、その後にチェックされています。ガードチェックが失敗した場合、エラーメッセージがプリントされ、プログラムは終了します。

     

-fstack-protector-all
      すべての機能が保護されていることを除いて-fstackプロテクターのような。

ます。http：// GCC。 gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Optionsする

Answer 3

プログラムはSIGSEGVで死亡したとき、それは通常、Unixでコアをダンプ。あなたは、デバッガにそのコアをロードし、スタックの状態をチェックしてもらえますか？