タグ付けされた質問 「segmentation-fault」

4
セグメンテーションフォールトは内部でどのように機能しますか?
「CPUのMMUが信号を送信する」と「カーネルが問題のあるプログラムにそれを送り、それを終了する」以外に、これに関する情報を見つけることができないようです。 私はそれがおそらくシグナルをシェルに送信し、シェルが問題のあるプロセスを終了して印刷することによってそれを処理すると仮定しました"Segmentation fault"。そのため、crsh(crap shell)と呼ばれる非常に最小限のシェルを作成して、この仮定をテストしました。このシェルは、ユーザー入力を取得してsystem()メソッドに渡すこと以外は何もしません。 #include <stdio.h> #include <stdlib.h> int main(){ char cmdbuf[1000]; while (1){ printf("Crap Shell> "); fgets(cmdbuf, 1000, stdin); system(cmdbuf); } } そこで、私はこのシェルを裸の端末でbash実行しました(下で実行せずに)。次に、セグメンテーション違反を生成するプログラムを実行しました。私の仮定が正しければ、これはa)クラッシュcrsh、xtermのクローズ、b)印刷しない"Segmentation fault"、またはc)両方のいずれかです。 braden@system ~/code/crsh/ $ xterm -e ./crsh Crap Shell> ./segfault Segmentation fault Crap Shell> [still running] 正方形に戻って、私は推測する。これを行うのはシェルではなく、その下のシステムであることを示しました。「セグメンテーション違反」はどのように印刷されますか?「誰」がやっているの?カーネル?他に何か?信号とそのすべての副作用は、ハードウェアからプログラムの最終的な終了までどのように伝播しますか?

2
Linuxは、メモリが不足するかどうかを確認せずにプロセスを強制終了しますか?
メモリを大量に消費するいくつかのプログラム(2〜5 GB)を連続して実行するコマンドを使用して、シェルスクリプトを実行していました。スクリプトの進行状況を確認するために戻ったときKilled、端末から報告されたように、プロセスの一部がであることに驚いた。いくつかのプログラムはKilled、後で開始されるプログラムの前にすでに連続して完了していましたが、その後、すべてのプログラムはセグメンテーションフォールトで失敗しました(コードのバグが原因である場合も、そうでない場合もあります)。 私が使用していた特定のクラスターの使用履歴を調べたところ、誰かが同時に複数のメモリー集約型プロセスを実行し始め、その結果、クラスターで利用可能な実メモリー(および場合によってはスワップスペース)を使い果たしたことがわかりました。私の知る限り、これらのメモリ集約型プロセスは、プログラムで問題が発生し始めたのとほぼ同時に実行を開始しました。 Linuxでプログラムがメモリ不足になると、プログラムが強制終了する可能性はありますか?そして、私が後で得たセグメンテーション違反は、プログラムの実行に使用できるメモリの不足によるものである可能性があります(コードのバグではなく)。


4
セグメンテーションフォールト(コアダンプ)-どこへ?それは何ですか?なぜ?
Linuxでセグメンテーションエラーが発生すると、エラーメッセージSegmentation fault (core dumped)が端末(ある場合)に出力され、プログラムが終了します。C / C ++開発者として、これは非常に頻繁に起こります。通常、それを無視してに進みgdb、無効なメモリ参照を再度トリガーするために以前のアクションを再作成します。代わりに、私はおそらくこの「コア」を代わりに使用できるかもしれないと考えgdbました。なぜなら、常に実行するのはかなり退屈であり、セグメンテーション違反を常に再現できるわけではないからです。 私の質問は3つです。 このとらえどころのない「コア」はどこに捨てられますか? 何が含まれていますか? 私はそれで何ができますか?

2
segfaultingプログラムからのパイプ出力
ttf2afm時々セグメンテーション違反を起こすプログラムと、特にそうではないプログラム(具体的には、tetex 3.0の一部)を呼び出すスクリプトがあります。必要な情報は常にセグメンテーション違反が発生する前に出力されますが、プログラムの失敗時にパイプのリダイレクトが失敗し、パイプに何も出力されないようにするのに苦労しています。 FIFOを介してリダイレクトを試行trueし、最後にプロセスをかっこで囲み、シェル関数から実行し、で囲みましたsh -cが、スクリプトはプロセスが何も、リダイレクトまたはその他を出力しないようにしました。 私はそれがコマンドラインから完全に出力できるが、何らかの理由でスクリプトからではないので、出力できることを知っています。 私の質問は、スクリプトがプログラムがセグメンテーション違反を起こし、出力を提供するという事実を無視する方法はありますか? BASH 4.1.10(2)-releaseを実行しています。

2
139(セグメンテーション違反)を返すプログラムをbashでトラップするにはどうすればよいですか?
一部のプログラムをテストするbashスクリプトがあり、そのプログラムの1つが返されるSegmentation faultため、スクリプトの先頭にトラップを追加しようとしました。 trap "echo 'segfault occured!'" SIGSEGV しかし、それは何もしませんでした。使った echo $? segfaultを生成するプログラムの直後に、出力として139が表示されます。特定のエラーコードのトラップを追加するにはどうすればよいですか?

2
.dtorsは書き込み可能に見えますが、segfaultを書き込もうとします
これはUbuntu 9.04、2.6.28-11-server、32ビットx86です。 $ cat test.c main() { int *dt = (int *)0x08049f18; *dt = 1; } $ readelf -S ./test ... [18] .dtors PROGBITS 08049f14 000f14 000008 00 WA 0 0 4 ... $ ./test Segmentation fault $ 開始されていない場合:gccは、終了.dtors後に呼び出されるelf実行可能ファイルにデストラクタセグメントを作成しmain()ます。このテーブルは長い間書き込み可能readelfでしたが、私の場合はそうであるように見えます(出力を参照)。ただし、テーブルに書き込もうとすると、セグメンテーション違反が発生します。 最近読み取り専用の.dtors、pltに移行する動きがあったことは承知していますが、私が理解していないのはreadelfとsegfaultの不一致です。

1
virtualGLを介してglxgearsを実行しようとすると、セグメンテーションエラーが発生する
(リモート接続を介して3Dを効率的に使用する方法のフォローアップ?) amd64パッケージをサーバーにインストールし、i386パッケージをクライアントにインストールしました。ユーザーガイドに従って、私はこれをクライアントで実行します: me@client> /opt/VirtualGL/bin/vglconnect me@server me@server> /opt/VirtualGL/bin/vglrun glxgears これによりsegfaultが発生vglconnect -sし、sshトンネルに使用しても機能しません。また、TurboVNCメソッドも試してみましたが、起動vglrun glxgearsは機能しますが、jpeg圧縮を使用してアプリケーションウィンドウのみを送信することをお勧めします。問題は32 <-> 64ビットですか?またはどうすれば修正できますか?

4
straceを実行するとOpenGLの問題がどのように修正されますか?
私のディストリビューション(PLD Linux)への最近の大きなアップグレード以来、私はたくさんのプログラムで問題を抱えています。言うまでもなく、OpenGLまたはPulseAudioのsegfaultに関係するすべてのもの。独自のnvidiaドライバーと3.2.xカーネルを使用しています。Xorg自体は問題なく動作し、ほとんどのプログラムを実行できますが、mplayer segfaultのようなもので、どのプログラムからも音が出ません。 それがOpenGLに関連している可能性があることがわかったら、私glxgearsはテストとして遊んだ。単独で実行すると、すぐにセグメンテーション違反が発生します。その後、私はそれstraceをうまく実行できることを発見しました。同じことがにも当てはまりますmplayer。テストmp3ファイルでそれを実行すると、即座にsegfaultが実行され、実行strace mplayerすると問題なく再生されます(ただし、パルスオーディオはまだ停止し、ダミーの出力デバイスに戻ります)。 何かを実行straceすると、segfaultingを防ぐことができ、状況をデバッグし続けるにはどうすればよいですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.