g ++でコンパイル中に不正な命令が発生する

Question

g ++でコンパイルされたlinuxで実行されているC++プログラムが、ある時間が経過して不正な命令例外が発生し、コアダンプが発生するという問題があります。 gdbを使用してバックトレースを行うと、私は得るでしょう

(gdb) bt 
#0 0x005e18cf in ATL_dpotrfL() from /usr/lib/liblapack.so.3gf 
#1 0x00000001 in ??() 
#2 0xb786f2e8 in ??() 
Backtrace stopped: previous frame inner to this frame (corrupt stack?) 

私はバックトレースにメインがない理由はわかりません。 ？デバッグシンボルが入っていない私のlinuxライブラリの一部であるようです。

私の質問は今ですか？このプログラムの問題は何ですか？図書館のラップは誤ってコンパイルされていますか（私は数日前にそれをコピーしました）？または他のエラーがありますか？

私は確かにアセンブラやそれに類するものはありませんでした。 C++のみ。通常壊しスタックを意味

おかげ クリスチャン

Answer 1

。特に0x00000001の値は、有効なスタックアドレスではない可能性が非常に低いので、スタック割り当てバッファをオーバーフローさせてリターンアドレスを上書きしたとします。

Answer 2

DeadMGは言っても、プラス何か：

不正な命令は通常、ランニングマシンでは使用できないCPU命令を使用するようにコンパイルされたバイナリの結果です。あなたは

g++ -msse4 ... 

のようにコンパイルして、SSE4命令セットをサポートしていないインテルのAtom CPU、上のことを実行する場合、これは、たとえば起こることができます。クラッシュは必ずしも起こらない。

int main() {} 

SSE4命令が生成されている間は、そうではありません。予想外のコードパスに対しても同様ですが、将来クラッシュすることはありませんが、将来はクラッシュすることはありません。

スタックスムージングコードを見つけるには、cppcheck or similar,ValgrindのようなLINT、分かりやすい古いprintf/coutデバッグ、またはチェックされたSTL実装を使用すると考えられます。

Answer 3

他の人が言っているように、あなたはおそらくあなたのスタックをねじ込んでいます。

最も一般的な原因は次のとおりです。

• は

スタック上の巨大なローカルデータを宣言尖った空間外

を書い悪いポインタ（すでに削除）

への書き込み原因を見つけるための魔法の方法は：

valgrind your_program [args] 

（通常は起動するコマンドの前に「valgrind」を追加するだけです。もしvalgrindをまだインストールしていないのであれば、ディストリビューションのパッケージは広く使われているので、ディストリビューションのパケットが必要です。）

それでvalgrindは実行中のプログラムを検査してしまいます。 （例えば、スタック上に）書込みが行われないようにします。