6

ローカル オブジェクトが非常に単純なプロシージャを呼び出そうとすると、HPUX 上のスレッド化された C++ プログラムでスタック オーバーフローが発生し、SEGV_MAPERR が発生するという問題に遭遇しました。私はしばらく戸惑いましたが、幸運にもこれをスタック サイズの問題として認識している誰かと話をしたところ、スレッドで使用できるスタック サイズを増やすことで問題を解決することができました。

スタックがオーバーフローしたことをどのように認識できますか? Windows/Linux/hpux で症状は異なりますか?

4

5 に答える 5

10

アプリを停止して「スタック オーバーフロー」と言うプラットフォームを使用していないと仮定すると、あらゆる種類のバッファ オーバーフローから見られるのと同じ動作が見られると思います。スタックは、プログラム用に事前に割り当てられた別のメモリ チャンクにすぎません。これらの境界の外に出た場合は、幸運を祈ります。あなたが何を踏むかは誰にもわかりません!

CPU から読み取った温度を上書きしたり、Larry に入力している電子メールであったり、カーネルがロックされていることを伝えるビットであったり、楽しいデッドロック状態を引き起こしたりする可能性があります。知るか。

C++ に関しては、メモリ内の他のものとの関係でスタックをどのように配置すべきか、またはこれがスタックである必要さえあるとは何も言っていません!

于 2009-02-18T21:48:57.973 に答える
2

スタックがオーバーフローしたことをどのように認識できますか?

スタックのサイズ、スタックの開始位置、およびメモリ内でのスタックの成長方向がわかっている場合は、スタック ポインターのアドレスを確認して、スタックの末尾を超えているかどうかを確認するだけです。C++ では、スタック ポインターへの直接アクセスは許可されていません。アセンブリで小さな関数を簡単に記述して、この分析を実行し、それをプログラムにリンクすることができます。

于 2009-02-18T23:42:14.397 に答える
1

0xC00000FDWindows の例外コード。

通常、SEH が機能しなくなったことに気付くと、診断が容易になります。

于 2009-02-18T21:57:21.073 に答える
0

少し話題から外れているかもしれませんが、Ada の類似の問題 (タスクでスタック領域が不足する) は、かなり一般的な「珍しい」エラーです。多くのコンパイラは、PROGRAM_ERROR 例外でタスクを停止します (ただし、メイン タスクは停止しません)。

ある意味では、これを嗅ぎ分けることができるに違いありません。「この大きな配列をタスク内に移動したところ、突然機能しなくなった」というようなことから始まる傾向があります。

于 2009-02-18T22:00:11.833 に答える
-1

画面への出力テキストが、テスト中のプログラムのコード行と混在するようになりました。また、以前の bash コマンドや、出所不明のその他のテキストも存在していました。プログラムのテキストが破損したことすべてに加えて。

于 2016-10-24T18:35:47.313 に答える