Come eseguire il debug di arresto del filesystem FUSE in Linux

Question

Attualmente sto sviluppando un'applicazione utilizzando il modulo del filesystem FUSE in Linux (kernel 2.6) in linguaggio C. A causa di alcuni errori di programmazione, l'applicazione si blocca dopo aver montato il filesystem. Dal momento che sono uno sviluppatore alle prime armi in ambiente Linux/C. Potresti per favore permettermi di dirmi le possibili opzioni per eseguire il debug di tali programmi?

Answer 1

Innanzitutto, assicurarsi di compilare con i simboli di debug abilitati (opzione -g su gcc). Prima di eseguire il programma, abilitare i core dump con il comando di shell:

ulimit -c unlimited 

Poi, quando l'applicazione si blocca, si lasceranno un file core nella directory di lavoro corrente (purché in grado di scrivere ad esso).

È possibile quindi caricare il file core nel debugger gdb:

gdb <executable file> <core file> 

... e ti mostrerà dove si schiantò, e ti permettono di esaminare le variabili e così via.

Answer 2

È possibile utilizzare Valgrind con FUSE, tuttavia read this first per informazioni su una soluzione setuid. Io in realtà faccio il seguente come vantaggio per gli altri che potrebbero aver bisogno di eseguire il debug il file system:

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

Io lavoro su FUSE molto .. e il 90% del tempo i miei arresti sono causa di una perdita, che fa sì che il OOM killer per agire, dereferenziare un puntatore cattivo, doppio free(), ecc. Valgrind è un ottimo strumento per catturarlo. GDB è utile, ma ho trovato Valgrind indispensabile.

Answer 3

Esegui il tuo client di fusibili con l'opzione -d.

Answer 4

So che questa domanda è piuttosto vecchia, ma se si utilizza lo switch -f verrà eseguito in primo piano, il che è molto utile per il debug. Lo switch -s disabilita il multithreading, che è anche molto utile.

Attualmente sto sviluppando un driver FUSE e questa pagina è stato molto utile: http://www.cs.hmc.edu/~geoff/classes/hmc.cs135.201109/homework/fuse/fuse_doc.html

Per citare:

Printf vostro printf/fprintf il debug del codice funziona solo se si esegue con il - f interruttore. Altrimenti, Fuse disconnette stdout e stderr.

Answer 5

UML è molto utile per eseguire il debug di parti generiche del kernel Linux come il filesystem, la pianificazione ma non la parte hardware o il driver specifico del kernel.

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

http://valerieaurora.org/uml_tips.html

E guardando il diagramma con attenzione:

Si vedrà l'applicazione "ciao" che sta attuando tutti i gestori di callback FUSE. Quindi la maggior parte del debug è nel programma userspace, dato che il modulo del kernel FUSE (e libfuse) è genericamente pensato per essere utilizzato dal filesystem ALL FUSE.