Cプログラムに次の問題があります。どこかにスタックオーバーフローがあります。最適化なしでデバッガーシンボルを使用してコンパイルしたにもかかわらず、プログラムは次の出力で終了します（Linuxではgdbの内部または外部）。
プログラムは信号SIGSEGV、セグメンテーション違反で終了しました。プログラムはもう存在しません。
これが実際にスタックオーバーフローであることを検出できる唯一の方法は、valgrindを介してプログラムを実行することでした。問題を特定するのに役立つコールスタックトレースをオペレーティングシステムに強制的にダンプさせる方法はありますか？
残念ながら、gdbではプログラムを簡単に利用することもできません。
システムがコア ファイルをダンプできるようにすると、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
GCCを使用すると、これを試すことができます。
-fstack-protector
スタックスマッシング攻撃などのバッファオーバーフローをチェックするために、追加のコードを発行します。これは、脆弱なオブジェクトを持つ関数にガード変数を追加することによって行われます。これには、allocaを呼び出す関数、および8バイトを超えるバッファーを持つ関数が含まれます。ガードは、関数が開始されるときに初期化され、関数が終了するときにチェックされます。ガードチェックが失敗すると、エラーメッセージが出力され、プログラムが終了します。
-fstack-protector-all
すべての関数が保護されることを除いて、-fstack-protectorと同様です。
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Options
プログラムが SIGSEGV で停止すると、通常は Unix でコアをダンプします。そのコアをデバッガにロードして、スタックの状態を確認していただけますか?