Discussion :

[pyros]

Salut à tous,

J'aimerais savoir s'il existe un option sur g++ pour "thrower" une exception en cas de segfault, à la manière de \EHa pour visual ?

J'utilise une lib qui a la fâcheuse tendance à écrire là où elle ne devrait pas et pour limiter la casse, j'enferme les appels à cette lib dans un gros try catch(...).

Je ne peux pas utiliser de signaux et j'aimerai avoir le moins de différences entre le code windows et le code linux, c'est pourquoi une option de compil serait la bien venu

Merci.

[Nhaps]

Je ne voie pas l’intérêt de faire un try/catch sur une erreur de segmentation.

Quel librairie utilises tu ?

[pyros]

L'intérêt est d'éviter de faire planter toute l'appli à cause d'un module secondaire qui a foiré. La lib s'appelle SMlib, c'est une lib de calcul géométrique.

[Nhaps]

Je voulais dire par la, qu'il faut la corriger en la trouvant avec l'aide d'un debuggeur et ensuite tu la corriges en conséquence.

[jblecanard]

Je voulais dire par la, qu'il faut la corriger en la trouvant avec l'aide d'un debuggeur et ensuite tu la corriges en conséquence.

Ce n'est pas forcément possible si la lib ne lui appartient pas, ce qui doit être le cas.

[pyros]

Ce n'est pas forcément possible si la lib ne lui appartient pas, ce qui doit être le cas.

Tout à fait. Et je me vois pas dire à l'utilisateur "Nan mais mon code il fonctionne, c'est la lib qui crash"

[pyros]

Apparemment ce n'est pas possible pour le moment. Y'a bien l'option -fobjc-exceptions, mais c'est pour de l'objectiveC.

Pour ceux que ça intéresse, ils peuvent chercher SEH (Structured Exception Handling) sur google. Il existe des moyens plus ou moins crade de gérer ça sous linux mais tous basé sur des signaux.

[jblecanard]

J'y pense que maintenant... t'as étudié les terminate handler de la STL ?

[Invité]

Bonjour,

Il est possible de détourner le comportement par défaut des différents signaux (fonction signal).
Ceci dit, par défaut il est interdit de lever une exception à ce moment, mais c'est également contournable via une option du compilateur : -fnon-call-exceptions

Ça peut donner ç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;
  }
}

[pyros]

@jblecanard
Je ne connaissais pas les terminate handler, d'après ce que j'ai compris, ça s'applique uniquement lorsqu'une exception n'est pas catché, ça marche aussi pour un segfault ?

@Nudger
J'avais vu ce genre de méthodes mais le problème d'un signal est qu'on ne peut le redéfinir qu'une fois. Et comme je ne sais pas si ce signal est, ou sera, utilisé par quelqu'un d'autre, je peux pas me permettre de l'utiliser

Merci pour votre aide mais le code a été intégré, donc plus de modif, sauf si demande explicite d'un utilisateur

[oodini]

Ce n'est pas forcément possible si la lib ne lui appartient pas, ce qui doit être le cas.

La bibliothèque a son code source ouvert. Il a donc la possibilité de savoir d'où vient l'erreur, et de la signaler au développeur de la bibliothèque.

[jblecanard]

La bibliothèque a son code source ouvert. Il a donc la possibilité de savoir d'où vient l'erreur, et de la signaler au développeur de la bibliothèque.

Quand tu as des délais, tu ne peux pas attendre que l'éditeur sorte un bug fix de son chapeau. Par contre, tu peux patcher toi même le code de la lib avant de l'envoyer chez le client. Pas génial mais ça dépanne.

[oodini]

Oui, c'est ce que je voulais dire (de manière un peu elliptique, je le confesse).