So debuggen Sie den Absturz des FUSE-Dateisystems unter Linux

Derzeit entwickle ich eine Anwendung mit dem FUSE-Dateisystemmodul unter Linux (2.6 Kernel) in der Sprache C. Aufgrund eines Programmierfehlers stürzt die Anwendung nach dem Mounten des Dateisystems ab. Da ich ein unerfahrener Entwickler in der Linux/C-Umgebung bin. Könnten Sie mir bitte mögliche Optionen zum Debuggen solcher Programme nennen?

Es gibt ein paar Funktionen von FUSE, die das Debuggen erschweren können: Es läuft normalerweise im Hintergrund (was bedeutet, dass es sich von stdin/out trennt) und ist multithreaded (was zu Race-Bedingungen führen kann und das Debuggen mit gdb komplizierter ist). Glücklicherweise können beide Funktionen deaktiviert werden:

1. Benutzen Sie die -f Wechseln Sie, um Ihre Anwendung im Vordergrund zu halten. Dadurch funktionieren Ihre printf-Zeilen.
2. Benutzen Sie die -s Schalter, um Multithreading zu deaktivieren. Das Deaktivieren von Multithreading schränkt die Leistung ein, verbirgt aber auch bestimmte Fehler (Race Conditions), vereinfacht die Verwendung von gdb und stellt sicher, dass die Ausgabe von printf lesbar ist (wenn mehrere Threads etwa gleichzeitig printf aufrufen, kann die Ausgabe durcheinander geraten).

Ich würde auch empfehlen, Geoff Kuennings zu lesen FUSE-Dokumentation.

Führen Sie Ihren Fuse-Client mit dem aus -d Möglichkeit.

Stellen Sie zunächst sicher, dass beim Kompilieren die Debugging-Symbole aktiviert sind (-g Option zu gcc). Bevor Sie Ihr Programm ausführen, aktivieren Sie Core-Dumps mit dem Shell-Befehl:

ulimit -c unlimited

Wenn die Anwendung dann abstürzt, hinterlässt sie ein core Datei im aktuellen Arbeitsverzeichnis (sofern darauf geschrieben werden kann).

Anschließend können Sie die Kerndatei in laden gdb Debugger:

gdb <executable file> <core file>

…und es zeigt Ihnen, wo es abgestürzt ist, und ermöglicht Ihnen die Untersuchung von Variablen usw.

Sie können verwenden Valgrind allerdings mit FUSE Lesen Sie dies zuerst um mehr über einen Setuid-Workaround zu erfahren. Eigentlich mache ich Folgendes aus Bequemlichkeit für andere, die möglicherweise mein Dateisystem debuggen müssen:

#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");
}

Ich arbeite viel an FUSE … und in 90 % der Fälle sind meine Abstürze auf ein Leck zurückzuführen, das dazu führt, dass der OOM-Killer Maßnahmen ergreift und einen fehlerhaften Zeiger, Double Free() usw. dereferenziert. Valgrind ist ein großartiges Tool, um das zu erkennen . GDB ist hilfreich, aber ich habe festgestellt, dass Valgrind unverzichtbar ist.

UML eignet sich sehr gut zum Debuggen allgemeiner Teile des Linux-Kernels wie Dateisystem und Planung, jedoch nicht für die Hardwareplattform oder den treiberspezifischen Teil des Kernels.

http://www.csee.wvu.edu/~katta/uml/x475.html

http://valerieaurora.org/uml_tips.html

Und schauen Sie sich das Diagramm genau an:

Sie sehen die Anwendung „hello“, die alle FUSE-Callback-Handler implementiert. Der Großteil des Debuggens erfolgt also im Userspace-Programm, da das FUSE-Kernelmodul (und libfuse) grundsätzlich für die Verwendung durch ALLE FUSE-Dateisysteme gedacht ist.