Segmentation Fault incomprehensible

Bonjour,

Mon code plante a l'execution avec le message d'erreur "segmentation fault" et, apres plusieurs heures d'arrachage de cheveux je n'arrive pas a resoudre le probleme.

Pour expliquer mon probleme :
- le programme lance une boucle de 150000 itérations ac les memes actions a chaque fois et plante au bout d'environ 110000 itérations
- biarre : le programme ne plante jamais lors de la meme itération, un cous de sera 109987, l'autre coups ce sera 109567 (toujours assez proche de 109/110k mais jamais au meme endroit)... Je ne pas comment c'est ossible car il n'y a rien d'aléatoire dans mon programme donc je m'attendrai a ce que ca plante toujours au meme moment ou que ca plante pas du tout.
- le code plante a l'appel d'une function virtuelle par une sous classe, Cette function est appele a chaque iteration sans probleme mais plante alors que ce sont exactement les memes éléments....

Voila, si vous avez une quelconque idée du type d'erreur qui pourrait expliquer mon probleme, en particulier les cas ou on peut avoir un programme qui plante de maniere "aléatoire" sans raison particulière.

Y a t-il moyen lorsqu'on l'on a ce type d'erreur d'avoir une explication plus approfondie (que simplement "Segmentation Fault") de ce qui a cause l'erreur ? En utilisant les debuggueur des IDE genre QT Creator ca peut m'aider peut-être ? Pour debugguer un programme quels sont les methodes efficaces / conseillés ? Car je suis débutant et ce que je fais est assez manuel en général : je mets des std::cout un peu partout dans le programme puis je le lance pour voir ou ca plante et je me demandais si il y avait plus simple et efficace....

Merci pour votre aide !

Si le programme plante toujours entre la 109k et la 110k itération, on ne peut plus vraiment parler de plantage aléatoire, juste une petite incertitude sur l'itération précise.

Quant à l'origine du problème, ce n'est souvent pas à la ligne où se produit la "segmentation fault" que se trouve le bug. Il s'agit d'une tentative d'accès en dehors des zones allouées.
Les causes fréquentes sont les déréférencement de pointeur nul, non initialisé, libéré, hors scope, l'écriture au delà de la fin d'un tableau, des excès de récursivité, des accès simultanés par plusieurs threads, etc.

Il existe pas mal d'outils permettant de surveiller et déboguer les accès mémoire, l'un des plus connus étant valgrind.

salut,

lorsque tu seg, tu peux générer un core (voir ulimit), puis utiliser gdb sur ton core pour avoir les dernières instructions avant le crash. Après comme pour toi c'est aléatoire je suis pas sûr que ca t'aide beaucoup.

Comme ca arrive aux alentours des 100k, je verrais bien une fuite mémoire et une alloc refusée à partir d'une certaine itération..
du coup (c'est jamais perdu) installes également valgrind (memcheck) et lance valgrind dessus pour voir si tu fuites pas.

Merci pour vos reponses !

Bon j'ai lance le memcheck de valgrind (sous Qt Creator Analyse--> Valgrind memory check) et la..... le code tourne parfaitement jusque la fin, je comprends pas du tout.

Lorsque je le lance en ligne de commande dans la console sous linux ca plante mais pas lancer en "memory check".

Ca s'appelle un Heisenbug

* Est-ce que ton code est multithread ? Une data-race peut produire ce genre de bug (tu veux lire une variable initialisé par un autre thread, sauf qu'un jour le thread a pas eu le temps de finir...) puis lorsque tu instrumente le code tout à coup le thread a tout le temps le temps de finir. À nouveau Valgrind peut t'aider http://valgrind.org/docs/manual/hg-manual.html (Si ton projet est petit un papier et un crayon aussi)

* Est-ce que ton code utilise des pointeurs (nus) ? Un pointeur effacé sous certaines conditions alors que tu dois encore y avoir accès peut provoquer ce genre de problème.

Je dirais donc Valgrind (ou équivalent), remplacement/habillage des pointeurs. c'est quelques jours de boulots pas marrant, mais si ca résoud pas ton bug ca en résoudra d'autres que t'as pas encore vu.

Salut,

Comme les autres te l'ont déjà indiqué, une erreur de segmentation n'est que le symptôme du fait que tu es aller charcuter la mémoire de ton application. C'est le symptôme, pas la cause qui, elle, peut avoir énormément d'origines (la plupart ont d'ailleurs déjà été citées au moins une fois).

Si ton programme fonctionne correctement en mode débug alors qu'il plante lamentablement en mode release, tu ne dois y voir qu'une chose : la confirmation du symptôme représenté par l'erreur de segmentation : tu vas bel et bien, à un moment donné, charcuter la mémoire et y foutre le bordel.

Il faut en effet avoir conscience de deux choses :

• le mode débug contient énormément d'informations supplémentaires par rapport au mode release : données de débuggage, instructions qui n'apparaissent dans le code binaire qu'en mode débug (assertion), et bien d'autres choses. Cela ralenti forcément l'exécution du programme ;)
• Le mode débug peut faire certaines choses que le mode release ne peut pas forcément, comme initialiser (ou réinitialiser) des pointeurs à des adresses spécifiques (voir à null), ajouter des symboles que le débuggeur poura utiliser, ... Tout cela pour permettre au débuggueur de faire son travail et de nous laisser voir "les entrailles" de l'application

Et, si tu ajoutes là dessus des outils d'analyses dynamique (comme valgring), tu perds encore -- du fait de l'utilisation de l'outil -- un tout petit peu de performances (il faut bien qu'il tienne le compte de toutes les ressources allouées et libérées ;) ).

Tout cela pour dire que le fait que le symptôme (l'erreur de segmentation) disparaisse en mode debug ou lorsque tu utilises valgrind est justement la preuve que, sans le code, nous ne pourront absolument rien faire.

Par contre, ce que nous pouvons faire, c'est te donner quelques pistes à explorer par toi-même ;) :

1. Evites les pointeurs à chaque fois que leur usage n'est pas indispensable : les références (éventuellement) présentent souvent une alternative bien plus sécurisante ;)
2. Utilises les pointeurs intelligents (std::unique_ptr, std::shared_ptr)chaque fois que possible
3. Chaque fois que tu écris un delete sur un pointeur, veille à l remettre à NULL (ou plutôt nullptr)
4. Chaque Avant chaque tentative d'accès à un pointeur, vérifie sa validité en t'assurant qu'il n'est pas égal à NULL (nullptr).
5. Sois particulièrement attentifs aux pointeurs qui sont référencés par différents éléments... On a vite fait "d'oublier" de mettre l'un des éléments à jour pour indiquer que le pointeur en question a été détruit ou qu'il a "changé de place".
6. Sépare très clairement la responsabilité qui permet l'utilisation de tes pointeurs de celle qui en permet le maintien. Pas seulement au niveau des fonctions, mais carrément au niveau de classes (ou de structures) différentes : le terme générique "manager" est une catastrophe pour le SRP ;)
7. J'en oublie surement, mais commence déjà par cela ;)

Merci beaucoup pour vos reponses,

je connais un peu les "segmentation Fault" mais ce qui m'intrigait dans le cas present c'etait le fait qu'elle n'apparaissait pas deux fois au meme moment du programme mais a des moments proches et sur des actions "repetes" (ie. ce n'etait pas logique qu'une action reussisse 1000 fois puis fail sans raison la 1000 et 1eme fois). Dans la plupart des cas, je pouvais voir directement ou etait la faute car le programme plantait toujours au meme endroit et en general c'etait plutot simple.

En plus c'est sur des bouts de codes de librairies externes (ITK/VTK pour ceux qui connaissent) donc j'avais du mal a croire que le probleme pouvait venir de la...

Bon j'ai reussi a faire tourner mon code et l'output semble bon, je vais voir plus tard si je peux avoir le fin mot de l'histoire et comprendre pourquoi cela tourne en debug et pas en release...

Parce que souvent, le mode débug va explicitement mettre à zero toutes les variables.

Pour moi, une segfault qui disparait en debug, c'est une variable utilisée sans avoir été initialisé.
surtout s'il n'y a pas de #if DEBUG

en fait pour peut-etre donner une idee le programme plante lorsque cette fonction (RequiresInitialization()) de la classe vtkCell est appele pour un sous classe de vtkCell qui est vtkTriangle dans la function "GetCell" de vtkUnstructuredGrid :

virtual int RequiresInitialization() { return 0;}

vous pouvez trouver le header complet de la classe (vtkCell) :

http://www.vtk.org/doc/release/4.0/h...8h-source.html

et la sous classe est la classe vtkTriangle ici :

http://www.vtk.org/doc/release/4.0/h...8h-source.html

et enfin la classe vtkUnstructuredGrid qui contient la function "GetCell" qui apelle la fonction qui plante "RequiresInitialization()" de la classe vtkTriangle herite de vtkClass

http://www.vtk.org/doc/nightly/html/...8h_source.html

Tu n’as pas précisé quel est ton environnement.

Si c’est sous windows, le debugger intégré à visual studio est excellent.

Si c’est sous linux, tu peux lancer ton programme avec gdb. Par contre, l’interface textuelle de gdb est un peu complexe. Lancer le programme depuis un IDE avec intégration gdb (qt creator, par exemple) est un moyen de rendre cela nettement plus convivial, sinon, il y a pas mal de tutoriels sur l’utilisation de gdb.

Je doute (mais je ne me prononcerais pas avec certitude) que le problème vienne de la vtk elle-même. Je pense plutôt que tu l’appelles mal à un moment (par exemple, un paramètre null qui ne devrait pas, ou avec une valeur arbitraire).

pour crasher dans une vtable, t'aurais pas un cast cavalier qui traine ?

Citation:

---

Envoyé par Bousk

pour crasher dans une vtable, t'aurais pas un cast cavalier qui traine ?

---

Ou mieux encore, un memset?

Citation:

---

Parce que souvent, le mode débug va explicitement mettre à zero toutes les variables.

---

j'ai également déjà eu le cas où il y avait incompatibilité binaire...

une certaine de tes librairies est compilée avec une certaine version de itk (par exemple),
puis tu upgrades itk vers une version supérieure.
Dans cette version supérieure tu as une classe qui est plus bincomp (ajout d'un champ par exemple) mais tu recompiles pas ta librairie.

et du coup dans ta librairie tu vas charcuter la mémoire, en debug pas de problème, pas d'assertions concernées, mais en release ... BANG :aie:

enfin bref, ca reste que de la spéculation, sans code, c'est un peu du majax

edit: pas vu le poste de Aujourd'hui, 14h29