0

自分が書いたスケジューラーをテストしようとしています。2つのプロセスをスケジュールします。どちらも無限のwhileループです（while（1）ステートメントのみ）。プログラムを実行すると、10秒（場合によっては5秒、場合によっては15秒以上）後にsegfaultが発生することがあります。場合によっては、セグメンテーション違反がまったく発生せず、期待どおりに実行されることがあります。セグメンテーション違反が発生する前に、両方のプロセスが期待どおりにスケジュールされていることを示すログファイルがあります。gdbを使用してエラーをデバッグしようとしていますが、あまり役に立ちません。これが私がバックトレースで得たものです：

#0  0x00007ffff7ff1000 in ?? ()
#1  0x000000000000002b in ?? ()
#2  0x00007ffff78b984a in new_do_write () from /lib64/libc.so.6
#3  0x000000000061e3d0 in ?? ()
#4  0x0000000000000000 in ?? ()

＃2はよくわかりません。

これはスタックオーバーフロー関連のエラーかもしれないと思います。ただし、プロセス全体で2回だけmallocします。2つのプロセスを設定するときはどちらも、作成したpcbテーブルのpcbブロックをmallocします。誰かが以前に同様の問題に遭遇したことがありますか？これは、スケジューラーでコンテキストを設定/交換する方法と関係がありますか？なぜそれは時々、そして時々そうではないセグメンテーション違反ですか？

4

2 に答える 2

1

質問に表示されているスタック トレースをどのように取得したかはわかりませんでした。

スタック トレースが偽物である可能性は非常に高く、スタックが破損しているからではなく、プロセスをアタッチするときやコア ダンプを調べるときに間違った実行可能ファイルを指定したなど、GDB を誤って呼び出したことが原因です。

よくある間違いの 1 つは、(これを実行可能ファイルと呼びましょう) を使用して実行可能ファイルをビルドし、-O2(この実行ファイルを呼び出しましょう)E1を使用して再構築し、GDBをシンボル ファイルとして指定して、実行中のライブ プロセスを分析しようとすることです。-gE2coreE1E2

それは機能しませんし、機能することが期待されていません。

于 2012-11-23T02:03:02.837 に答える
0

スタックが壊れているように見えるので、スタック バッファ オーバーフローがどこかにあることはおそらく正しいでしょう。コードがないと、わかりにくいです。

mallocしかし、これはあなたの電話とは何の関係もありません。動的に割り当てられたバッファーがオーバーフローすると、スタックではなくヒープが破損します。

おそらく確認する必要があるのは、次のように、コピーしようとしているデータに対して十分な大きさではないローカル変数です。

char xyzzy[5];
strcpy (xyzzy, "this is a bad idea";

または、指定したよりも多くのデータを書き込むシステムコールにバッファー (これもおそらくスタック上) を渡します。

もちろん、理論的には、これらが最も可能性の高い原因ですが、未定義の動作が原因である可能性があります。この回答に基づいて解決策が明らかでない場合は、おそらく原因となったコードを投稿する必要があります。それを行うときは、バグを示す最短の完全なプログラムになるように、可能な限り削除するようにしてください。

多くの場合、それを行うことで問題が明らかになります:-)

于 2012-11-22T21:34:57.777 に答える