Segfault .. pas d'exception ?

Salut, j'ai un petit souci dans mon programme qui est le suivant :
J'ai un crash à l'exécution (à mon avis de type segfault ) qui est en plus de cela aléatoire (pas à chaque exécution donc à mon avis c'est une histoire d'initialisation ou quelque chose dans le genre ) mon objectif est donc de repérer l'endroit de l'erreur.

Ma question est donc simple : le segfault déclenche-t-il une exception ? si oui laquelle ? (runtime_error ?) sinon comment faire pour repérer mon erreur (sans logger toutes les opérations sinon je me tire une balle j'en ai pour des années !!!)

Voila @++
Seb

utilise un debugger ça sera plus simple si tu veux pas faire des sorties dans un fichier log :)

OK je voudrais bien utiliser le débugger mais ca fait 25 fois qu'il me dit qu'il faut recompiler le projet avec les infos de débuggage et que au finale je peut pas le lancer mon débugage .... ^o) (jsui sous DEVCpp)

Sous un système unixoïde: Aucune idée, mais tu peux toujours essayer la solution de lancer une exception dans le traitement du signal...

Sous Windows: Une Access Violation (l'équivalent d'une segfault) est une exception Win32, pas une exception C++. Toutefois, les bibliothèques run-time Microsoft proposent des fonctions pour convertir automatiquement toute exception Win32 en exception C++.

Bon effectivement aparemment il existe une solution pour récupérer les exceptions windows mais elle utilise _set_se_translator(); contenue dans la bibliotheque runtime de windows qui se trouve aparemment sur VisualC++

Comment l'utiliser avec DEVC++ ???
Merci d'avance
Seb

Citation:

---

Envoyé par Médinoc

Sous un système unixoïde: Aucune idée, mais tu peux toujours essayer la solution de lancer une exception dans le traitement du signal...

---

La lancée d'exception dans un gestionnaire de signal est un comportement indéterminée (et en tout cas, la seule fois que j'ai essayé, c'était sous mingw sous windows, et ça marchait pas, je ne sais pas si ça marche sur une autre architecture/compilateur/OS).

Citation:

---

on effectivement aparemment il existe une solution pour récupérer les exceptions windows mais elle utilise _set_se_translator();

---

La fonction signal marche également ;) Au passage, Segmentation fault est une interruption (ou signal) (SIGSEGV) lancée par la MMU (qui indique un accès illégal à la mémoire).
Cela n'a aucun rapport avec les exceptions du C++ (lancée par throw)

Citation:

---

Envoyé par millie

Au passage, Segmentation fault est une interruption (ou signal) (SIGSEGV) lancée par la MMU (qui indique un accès illégal à la mémoire).
Cela n'a aucun rapport avec les exceptions du C++ (lancée par throw)

---

C'est bien ce que j'ai dit: Sous Win32, ça se traduit par une exception Windows (EXCEPTION_ACCESS_VIOLATION), récupérable avec du Structured Exception Handling (SEH), par opposition aux exceptions C++ que l'on récupère avec des try/catch.

Sous Win32, je suppose que l'exception Win32 arrive en premier, et que si elle n'est pas traitée, elle débouche sur un signal SIGSEGV (ou sur une exception C++ si _set_se_translator() a été appelée).

Citation:

---

Envoyé par Médinoc

Sous un système unixoïde: Aucune idée, mais tu peux toujours essayer la solution de lancer une exception dans le traitement du signal...
.

---

sous système unixoide, tout bon debugger fait ça :P (enfin on n'a pas besoin de le faire, il se charge de capter et même d'amener sur la ligne en cause et de fournir la pile d'appel..)

ddd par exemple...

Mais là, le programme lui-même ne le sait pas.
Ce qu'on cherche ici, c'est à obtenir une exception C++ au lieu d'un signal SIGSEGV. Et ça, je ne vois pas comment un debugger peut y faire grand-chose...

Il y avait eu cette discussion ci il y a peu de temps :

http://www.developpez.net/forums/sho...d.php?t=349829

(edit, devC++ dispose de gdb qui marche très bien pour repérer les erreurs de segmentation. Attention, il faut spécifier l'option -g lors de la compilation)

Parlons-en, de Dev-C++ : Il n'utilise pas GDB pour déboguer ses propres erreurs de segmentation quand il a un problème avec l'autocomplete : Il est probable qu'il utilise du SEH...