現在、Linux(2.6カーネル)のFUSEファイルシステムモジュールをC言語で使用してアプリケーションを開発しています。プログラミングエラーが原因で、ファイルシステムのマウント後にアプリケーションがクラッシュします。私はLinux/C環境の初心者開発者なので。そのようなプログラムをデバッグするための可能なオプションを教えてください。
5 に答える
FUSE には、デバッグを困難にする機能がいくつかあります。通常はバックグラウンドで実行され (つまり、stdin/out から切り離されます)、マルチスレッド化されます (競合状態が発生する可能性があり、gdb でのデバッグがより複雑になります)。幸いなことに、両方の機能を無効にすることができます。
- スイッチを使用
-f
して、アプリケーションをフォアグラウンドに保ちます。これにより、printf 行が機能するようになります。 - スイッチを使用して
-s
マルチスレッドを無効にします。マルチスレッドを無効にするとパフォーマンスが制限されますが、特定のバグ (競合状態) が隠され、gdb の使用が簡素化され、printf 出力が確実に読み取れるようになります (複数のスレッドがほぼ同時に printf を呼び出すと、出力が混同される可能性があります)。
Geoff Kuenning のFUSE ドキュメントも読むことをお勧めします。
オプションを使用してヒューズ クライアントを実行し-d
ます。
まず、デバッグ シンボルを有効にしてコンパイルしていることを確認します (-g
オプション to gcc
)。プログラムを実行する前に、シェル コマンドでコア ダンプを有効にします。
ulimit -c unlimited
その後、アプリケーションがクラッシュするcore
と、現在の作業ディレクトリにファイルが残ります (書き込み可能な限り)。
その後、コア ファイルをgdb
デバッガーにロードできます。
gdb <executable file> <core file>
...そして、クラッシュした場所が表示され、変数などを調べることができます。
ValgrindはFUSEで使用できますが、最初にこれを読んで、setuidの回避策について学習してください。私のファイルシステムをデバッグする必要があるかもしれない他の人のために、私は実際に以下を行います:
#include <valgrind/valgrind.h>
if (RUNNING_ON_VALGRIND) {
fprintf(stderr,
"******** Valgrind has been detected by %s\n"
"******** If you have difficulties getting %s to work under"
" Valgrind,\n"
"******** see the following thread:\n"
"******** http://www.nabble.com/valgrind-and-fuse-file-systems"
"-td13112112.html\n"
"******** Sleeping for 5 seconds so this doesn't fly by ....",
progname, progname);
sleep(5);
fprintf(stderr, "\n");
}
私はFUSEによく取り組んでいます..そして、クラッシュの90%はリークが原因で、OOMキラーがアクションを実行したり、不正なポインターを逆参照したり、free()をダブルしたりします。Valgrindはそれをキャッチするための優れたツールです。 。GDBは役に立ちますが、Valgrindが不可欠であることがわかりました。
UML は、ファイルシステム、スケジューリングなどの Linux カーネルの一般的な部分のデバッグには非常に適していますが、カーネルのハードウェア プラットフォームやドライバー固有の部分のデバッグには適していません。
http://www.csee.wvu.edu/~katta/uml/x475.html
http://valerieaurora.org/uml_tips.html
そして、図を注意深く見てください:
すべての FUSE コールバック ハンドラを実装しているアプリケーション「hello」が表示されます。したがって、FUSEカーネルモジュール(およびlibfuse)は一般的にすべてのFUSEファイルシステムで使用されることを意図しているため、デバッグの大部分はユーザー空間プログラムにあります。