Le moyen le plus simple de localiser un défaut de segmentation

+1 pour la réponse de Tibor.

Sur des programmes plus volumineux ou si vous utilisez des bibliothèques supplémentaires, il peut également être utile de consulter le backtrace avec gdb :ftp://ftp.gnu.org/pub/old-gnu/Manuals/gdb/html_node/gdb_42.html

Utilisez un débogueur, tel que gdb ou si ce n'est pas applicable un strace outil pour mieux comprendre où se produit l'erreur de segmentation.

Si vous utilisez gcc , assurez-vous de compiler avec -g commutateur pour inclure les informations de débogage. Ensuite, gdb vous montrera l'emplacement exact dans un code source où il segfaults.

Par exemple, si nous avons ce programme manifestement défectueux :

nouveau.c

#include <stdio.h>

int main()
{
        int *i = 0x478734;
        printf("%d", *i);
}

Nous le compilons avec gcc -g new.c -o new puis exécutez le gdb séance avec gdb new :

Nous émettons le run commande dans la session interactive et le reste est clair :

(gdb) run
Starting program: /home/Tibor/so/new
[New Thread 9596.0x16a0]
[New Thread 9596.0x1de4]

Program received signal SIGSEGV, Segmentation fault.
0x0040118a in main () at new.c:6
6               printf("%d", *i);
(gdb)

Comme DasMoeh et netcoder l'ont souligné, lorsqu'une erreur de segmentation s'est produite, vous pouvez utiliser le backtrace commande dans la session interactive pour imprimer une pile d'appels. Cela peut aider à mieux localiser l'emplacement d'une erreur de segmentation.

Le plus simple est d'utiliser valgrind . Il indiquera l'emplacement où l'accès invalide se produit (et d'autres problèmes qui n'ont pas causé de plantage mais qui étaient toujours invalides). Bien sûr, le vrai problème pourrait être ailleurs dans le code (par exemple :pointeur invalide), donc la prochaine étape est de vérifier la source, et si toujours confus, utilisez un débogueur.