Discussion :

[Sphost]

Bonjour à tous,
J'aurais besoin d'une piqure de rappel.
Autant avec C++ il est possible de catcher les exceptions standard, autant je n'arrive pas à récupérer les erreurs du style floating point exception. Comment puis-je "trapper" ces erreurs et obtenir la ligne où s'est produite cette erreur ? Ou tout bêtement, si il est impossible de la trapper, d'avoir juste le numéro de ligne où s'est produite l'erreur.

Environnement : Linux, g++

NB : l'utilisation du debugger pour obtenir l'information n'est pas envisageable, il s'agit d'une application devant tourner en production et pour laquelle on doit être capable de tracer les erreurs.

Merci d'avance pour votre aide.

[nicroman]

Ha ... ben ce ne sont pas des exceptions à proprement parler....
Le fait que Windows tranforme ces interruptions processeurs en exception est propre à windows, et je ne saurai t'aider sous Linux...


De toute manière tu n'auras pas (à mon avis) le fichier et la ligne ou s'est produite l'erreur, d'autant plus en 'release' (production) ou les informations de débuggage (fichier/ligne) n'existent pas.
Le seul moyen est de lancer toi même l'exception avec de jolis __FILE__ __LINE__ (ou __FUNCTION__) dans le constructeur...

[Médinoc]

Sous POSIX, certaines exceptions te parviennent sous forme de "signaux" : SIGFPE, SIGSEGV, etc.
Voir la fonction C signal() (très mal conçue car elle n'accepte pas de contexte) dans le man, ainsi que la fonction POSIX sigaction().

[Sphost]

Sous POSIX, certaines exceptions te parviennent sous forme de "signaux" : SIGFPE, SIGSEGV, etc.
Voir la fonction C signal() (très mal conçue car elle n'accepte pas de contexte) dans le man, ainsi que la fonction POSIX sigaction().

Merci beaucoup !
Effectivement la fonction sigaction m'a permis de récupérer le signal SIGFPE.
Je fais appel ensuite à la fonction backtrace dans ma fonction trappant le signal pour obtenir des informations sur la pile d'appel afin de savoir où se situe mon erreur ainsi que le numéro de ligne en utilisant la fonction linux addr2line.
--> Nice.

Le problème est qu'en mode release, autant le catch de signal via sigaction fonctionne parfaitement, la fonction backtrace devient, quant à elle, beaucoup moins "bavarde", il me devient ainsi impossible d'obtenir l'ensemble de ma pile d'appel et par conséquent savoir exactement où à lieu l'erreur...

Quelqu'un aurait-il une solution ?

Thx.

[nicroman]

Ben non... vu que les informations n'existent pas en release (j'ai l'impression de me répéter là ).

Maintenant, il est possible de faire une "release" (toutes options d'optimisation) avec les informations de debugging (file/line) je pense.

Attention a la pile... si le problême est un fourvoiement de mémoire/pile, tu risque d'avoir des choses bizarres dedans

[Sphost]

Ben non... vu que les informations n'existent pas en release (j'ai l'impression de me répéter là ).

Maintenant, il est possible de faire une "release" (toutes options d'optimisation) avec les informations de debugging (file/line) je pense.

Attention a la pile... si le problême est un fourvoiement de mémoire/pile, tu risque d'avoir des choses bizarres dedans

Ma question est : Y a-t-il une autre solution que backtrace ou ajouter des traces manuelle pour répondre à mon soucie mais merci qd même de m'avoir répondu
Par contre j'avais effectivement pensé à compiler mon mode release avec les information de debugging mais quid des performances ? Je suis sur une installation qui nécessite des temps de réponses rapide (lié à des automates pour une informatique de production.
Puis-je trouver qque part des benchmarks sur ce sujet (je ne peux pas faire actuellement de test sur l'application car nous commençons que maintenant les développements...)

Encore merci pour ton aide !

[Sphost]

Ma question est : Y a-t-il une autre solution que backtrace ou ajouter des traces manuelle pour répondre à mon soucie mais merci qd même de m'avoir répondu
Par contre j'avais effectivement pensé à compiler mon mode release avec les information de debugging mais quid des performances ? Je suis sur une installation qui nécessite des temps de réponses rapide (lié à des automates pour une informatique de production.
Puis-je trouver qque part des benchmarks sur ce sujet (je ne peux pas faire actuellement de test sur l'application car nous commençons que maintenant les développements...)

Encore merci pour ton aide !

En réponse à ma question :
Il semblerait que l'ajout des informations de debug n'impact pas sur le temps d'execution, seul la taille de l'exécutable s'accroit.

[Sphost]

Comme vu dans les posts précédant :
Je suis dans un cas où je fais appel à une fonction d'une librairie codée en Fortran depuis C++.
Je ne suis pas propriétaire de ce code.
Pour éviter tout crash de l'application je souhaites récupérer toutes les erreurs de type Floating point exception.
J'ai donc utilisé la fonction Sigaction au sein de mon code C++ pour définir un handler de signal SIGFPE.
Quand un signal SIGFPE est levé côté Fortran, je le récupère côté C++ via ce handler.
Je trace la pile via backtrace au sein de cette fonction.

Le problème par contre est qu'une fois la fonction handler terminé, je retourne dans ma pile d'appel à l'endroit où le SIGFPE a été levé et là l'erreur se produit de nouveau (et ainsi de suite....)

Je souhaiterais, une fois arrivée à la fin de ma fonction handler, pouvoir rester dans mon code C++ (ne pas retourner là où le signal a été levé) mais cela signifie que ma CallStack doit être "nettoyé".
J'ai du mal à voir comment ... Si quelqu'un a une idée ? Ou alors un moyen différent du mien pour gérer mon problème.

Merci d'avance

[Médinoc]

Ce qu'on m'a appris pour éviter de "retourner à l'erreur", c'est de faire un longjmp() dans la fonction passée à signal(). Mais je ne pense pas que longjmp() et C++ fassent bon ménage... (au niveau des destructeurs...).

Ou bien tu peux essayer en lançant simplement une exception C++...

[loufoque]

Tu exécutes le code dans gdb et tu fais bt.