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 !