Faire un try catch en cas de segmentation fault

Bonjour, je cherche un moyen de faire une sorte de try catch en cas de segmentation fault dans une fonction

j’ai regarder ici avec les jump mais hélas cela ne fonctionne pas, le segmentation fault arrete mon programme.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <stdio.h>
#include <setjmp.h>

#define TRY do{ jmp_buf ex_buf__; if( !setjmp(ex_buf__) ){
#define CATCH } else {
#define ETRY } }while(0)
#define THROW longjmp(ex_buf__, 1)

int
main(int argc, char** argv)
{
   TRY
   {
      printf("In Try Statement\n");
    const char *s = NULL;
    printf( "%c\n", s[0] );
   }
   CATCH
   {
      printf("Got Exception!\n");
   }
   ETRY;

   printf("finish !!!\n");

   return 0;
}

dans mon code, je voudrais que le programme continue et m’affiche finish !!!

es ce possible de le faire en C ?

Salut,

Comme tu le vois avec tes macros, le TRY est censé fonctionner avec le THROW : TRY définit un point où sauter, et THROW réalise le saut.

Avec un sefault, aucune notion de saut, juste un signal envoyé au programme. Il est possible d’attraper ce signal et de le traiter, mais il est fortement déconseillé de continuer comme si de rien n’était.

J’éviterais de bricoler un mécanisme d’exceptions en C si j’étais toi, et comme le dit mon VDD, j’attaperais ce signal pour le traiter : http://manpagesfr.free.fr/man/man2/signal.2.html

Si tu utilises MSVC, tu peux éventuellement te reposer sur ça : https://msdn.microsoft.com/fr-fr/library/s58ftw19.aspx

Ça ne répond pas à ta question, mais ça m’a rappelé ça (2012 déjà…)

Je pense que la réponse à ta question devrait être simplement : "n’essaye pas de faire ça, pauvre fou", mais si c’est juste pour impressionner ton voisin, tu peux essayer de rattraper SIGSEGV à la main (la manière de le faire dépendra de ton système, typiquement les *sigaction* sous Unix like).

Édit : j’avais pas vu les réponses ci-dessus, c’est un peu un doublon du coup

Ton programme d’exemple a un comportement indéfini (on ne peut pas écrire de programme C valide qui déréférence le pointeur NULL), donc un compilateur correct de C a le droit de faire tout ce qu’il veut avec. En particulier, il peut le transformer en un programme qui ne fait rien – toujours, quel que soit le code de TRY/CATCH que tu inclus. Le compilateur sur lequel tu testes ton programme fait peut-être ce que tu veux sur ce programme, mais ce n’est que temporaire, un autre compilateur ou une prochaine version de ton compilateur pourra faire autre chose.

Il ne faut pas écrire de programmes au comportement indéfinis en C, et en particulier c’est une perte de temps d’essayer de leur faire faire quelque chose de précis.

Edit: ça n’empêche pas bien sûr d’utiliser setjmp/longjmp pour construire un mécanisme d’exceptions. Mais tu ne peux pas "rattraper un segfault", en tout cas un segfault provenant d’un code au comportement indéfini.

Salut,

Déjà quasiment 6 ans ? ^^"

Sinon, pour compléter ce qui a été dit, la norme C (depuis la norme C99) précise qu’après l’exécution d’une fonction de traitement pour le signal SIGSEGV (et d’autres), le comportement est indéterminé (ISO/IEC 9899:201x, N1570, par. 7.14.1.1, al. 3, p. 247). En gros, rien ne garantit que l’exécution du programme va reprendre.

Édit : sans compter que, visiblement, le comportement est différent suivant que le signal est envoyé au processus ou déclencher par le processus lui-même (par exemple en déréférançant une adresse invalide). C’est en tous les cas ce que j’observe sous OpenBSD.