Discussion :

[deubelte]

Bonjour

J'ai fait un programme qui provoque un access violation. C'est bien sur fait exprès. Je voudrais savoir la commande qui me permet de catcher une telle exception:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
int *e=new (int[3]);
 
	int *p=e;
	int *p1=e+1;
	int *p2=e-1300;
	try{
	*p2=4;
	}
	catch(...){
		cout<<"error";
	}

merci

[Invité]

Bonsoir,

De base, un signal ne déclenche mais d'exception.
Mais il est possible de surcharger le traitement par défaut comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <iostream>
#include <signal.h>
 
void catch_segv(int sig) {
  signal(SIGSEGV, catch_segv);
  throw strsignal(sig);
}
 
int main() {
  signal(SIGSEGV, catch_segv);
 
  int *e=new (int[3]);
  int *p=e;
  int *p1=e+1;
  int *p2=e-1300;
 
  try {
    *p2=4;
  } catch( char* msg ) {
    std::cout << "Catched: " << msg << std::endl;
  }
}

Nécessite une compilation avec l'option -fnon-call-exceptions.

[deubelte]

ok merci
mais ce n'est pas un exception C++, alors est-ce bien de la catcher?

[Invité]

Pourquoi est-ce que ça serait un risque ?
Qu'envisagez-vous de faire dans votre "catch" ?

[pyros]

Bonjour,

J'avais posé la même question mais je n'avais pas eu beaucoup de réponse :
http://www.developpez.net/forums/d10...p/#post5844773

Sous visual, tu peux spécifier l'option \EHa (prop. du projet->C/C++->Code Generation->Enable C++ Exception->Yes with SEH Exception) qui te throw une exception en cas de segfault, mais pas pour g++.

Le problème d'utiliser les signaux, c'est que tu n'es jamais sûr que quelqu'un d'autre n'utilise pas déjà le signal pour autre chose (on ne peut affecter qu'une seule action par signal si je me souviens bien).

Après, je dirais que d'essayer de cacher un segfault sous le tapis est dangereux car tu ne sais pas dans quel état se trouve la mémoire à ce moment là (même si dans 99% des cas elle n'a subit aucun dommage), et donc tu ne sais pas si ton programme pourra continuer normalement.

La meilleur chose à faire serait de trouver la source du problème, mais bon dans la vrai vie on peut pas toujours...

[koala01]

Salut,

Le gros problème, c'est que tu ne peux avoir strictement aucune idée de ce qui se trouve à e-1300, ni de l'usage qui en est fait...

Tu peux, tout aussi bien, te trouver au milieux d'une chaine de caractères à afficher (qui sera tronquée, dans le meilleur des cas), au beau milieu d'une fonction hyper sensible (qui, manque de bol, sera appelée si tu attrape le problème ) ou ... entre deux membres d'une structure personnelle.

Il t'est donc particulièrement difficile de déterminer le "moins mauvais" traitement à effectuer si tu arrive à attraper cette erreur

Ne crois tu pas que le mieux (en dehors de résoudre le problème de logique sous jascent, bien sur) serait dés lors de... laisser planter purement, simplement et brutalement l'application

[JolyLoic]

Ne crois tu pas que le mieux (en dehors de résoudre le problème de logique sous jascent, bien sur) serait dés lors de... laisser planter purement, simplement et brutalement l'application

Je suis d'accord que le mieux (en fait, le seul comportement raisonnable) est que l'application s'arrête. Il y a des environnements où un arrêt par plantage n'est pas une bonne alternative, et où on peut vouloir tenter (sans aucune assurance de succès, ne pas se baser dessus pour une gestion de sécurité) 2 ou 3 choses avant l'arrêt (sauver un fichier de log, monter un message plus user friendly...)

[deubelte]

Je compile sous visual Studio.
J'ai fait expres que e-1300 tombe dans une zone ou il y a des ?? ?? ?? ??

Savez a quoi correspondent ces zones?


Merci

[koala01]

Je suis d'accord que le mieux (en fait, le seul comportement raisonnable) est que l'application s'arrête. Il y a des environnements où un arrêt par plantage n'est pas une bonne alternative, et où on peut vouloir tenter (sans aucune assurance de succès, ne pas se baser dessus pour une gestion de sécurité) 2 ou 3 choses avant l'arrêt (sauver un fichier de log, monter un message plus user friendly...)

Avec le risque (aussi minim soit il ) que la corruption de mémoire se fasse, justement (c'est vraiment pas de bol, je te l'accorde ) dans une des fonctions en charge de la création du fichier log ou de montage du message

Je compile sous visual Studio.
J'ai fait expres que e-1300 tombe dans une zone ou il y a des ?? ?? ?? ??

Savez a quoi correspondent ces zones?


Merci

Ce sont simplement des zones inaccessibles au débuggeur, sans doute parce qu'elles ne sont pas accessibles depuis les assemblies

[deubelte]

Puisqu'on est dans les généralités, j'en ai un autre qui concerne des formulations que l'on retrouve très souvent dans la Norme, la msdn...

ce sont les trucs dans ce style:

declarator:
direct-declarator
ptr-operator declarator

direct-declarator:
declarator-id
direct-declarator (parameter-declaration-clause) cv-qualifier-seq_opt exception-specification_opt
...
cv-qualifier-seq:
cv-qualifier-seq_opt
cv-qualifier:
const
volatile

J'imagine qu'il s'agit d'une formule théorique, mais ce signifie le _opt (en indice).

merci