Bonjour,
 
Toujours dans ma découverte du C, je recherche une capture des erreurs de code, pour transmettre quelques infos à stderr avant la fin du monde (enfin juste avant le crash de l'appli, ça suffira).
 
J'ai bien tout lu setjump.h et ucontext.h et j'avoue être un peu perplexe.
 
Quelqu'un aurait-il un code d'exemple ?
 
Je cherche à implémenter un code d'exception qui soit un passage obligé du programme avant sa sortie pour imprimer des choses simples, genre la ligne de plantage, la fonction en cours, ce qui sera toujours mieux que "exception fault" sans repères.
 
Je compile sous cygwin pour i686 et qu'en C, pas en C++.
 
Merci pour votre aide.

Il n'y a pas d'exceptions en C.
 
Pour ce qui est setjump et compagnie c'est pas vraiment ce que tu veux, surtout si tu commences.
 
En C on gère les erreurs en retournant des valeurs.

Même avec un ASM en tête de main pour contrôler la chute, il n'y a rien ?  
Ca m'étonne que personne n'ait approché le problème et donc mis un contournement en place ?!
 
Je débute en C, pas en prog, donc même si vous avez des exemples qui font peur, je prend.
 
Sinon, comment contrôles-tu, regexp42, un "exception fault" ?
Tu te le manges et c'est tout ?
Bof, je pense qu'on peut mieux faire et que certains ont trouvé.

1) Si tu es sous Unix/Linux (sous windows, laisse tomber, vu comment l'émulation de signal marche)
2) Si tu as du temps à perdre
Tu peux t'inspirer des techniques explicitées ici: http://www.smartango.com/articles/ [...] n-handling
Mais à la base, le langage C n'est pas fait pour cela, si tu ne veux pas d'exception fault, tu écris du code clean qui n'en génère pas (et c'est la l'art d'un bon programmeur C, de savoir gérer les accès mémoire avec précaution).
A+,

Mais bien sur et l'erreur n'est pas humaine !!
 
Je compte en moyenne 10-15mn de test par ligne de code sur des prog indus de 15 à 35000 lignes dans des langages simples à boucles de contrôles minimales et bordées (Automates, superviseurs, labview, etc ...).
 
Il y aura toujours des erreurs, tant que personne n'aura inventé le contrôle automatique du génie logiciel, un peu un saint Graal inaccessible.
Donc, en attendant, je préfère "perdre du temps", bien que je pense en gagner à la fin sans revenir sans cesse à la construction de la roue pour des erreurs de bases.
 
Plus je saurai d'où vient une erreur fortuite, plus rapide sera la résolution.
 
 
Et je suis sous Linux, pas sous Windows, je ne suis pas fou.

Mais ça n'a rien à voir avec la folie! Je ne vois pas ce qu'une telle réflexion vient faire ici.
 
C'est tout a fait possible sous windows, c'est même un mécanisme très robuste, le Structured Exception Handling, ou SEH, et ça existe depuis 10 bonnes années au moins. Simplement, il faut utiliser des extensions spécifiques au compilateur, et les techniques à utiliser sont différentes de celles sous linux.
 
Quand à l'erreur humaine, en ce qui concerne le C, si on parle de programmeurs expérimentés avec 10 années de programmation C ou plus, c'est principalement dans l'utilisation de fonctions dont le comportement est mal documenté que les erreurs vont survenir.
 
A+,

Personne ne t'interdit de faire du B ou du Z avant de faire ton programme en C

Sous linux, s'il y a génération d'un core dump, une étude de la pile d'appel donne un maximum d'information en général.  
A+,

Du concret s'il vous plait messieurs.
 
Du core dump, très bien, mais sur quelle base, quelle bibliothèque, quel mécanisme ? Il faut paramétrer le makefile différemment en gcc sous cygwin pour obtenir un code de sortie additionnel ?
 
Que vous faut-il comme informations pour m'aiguiller concrètement ?

Le mécanisme est automatique depuis les premiers Unix. Si un programme qui plante ne génère pas un core dump, c'est parce que le système a été configuré pour l’empêcher, avec un "ulimit -c 0" dans un scripts de boot par exemple. Il suffit de réactiver la génération des core dumps en faisant "ulimit -c unlimited".
Et sur un core généré, il suffit de lancer gdb. Voir par exemple ici: http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html
A+,

Donc sur un Samsung Arm 920T et son noyau propriétaire, je n'ai pas de solution car ils ont déjà limité pas mal de choses en empêchant l'accès au framebuffer et il faut contourner pour y arriver, l'accès aux fonctions shutdown, etc ...
Une idée pour arriver à générer des core dumps ?

 
Faudrait savoir.
 
En supposant que le deuxième message est correct, sous Unix un programme se termine de trois manières:
 
- en exécutant exit (y compris le retour de main()) -> tu enregistres qqch avec atexit.
 
- en exécutant _Exit/_exit -> tu peux rien faire
 
- en recevant un signal.  La plupart permettent l'instantallation d'un gestionnaire, voir signal et sigaction.

Je compile sous Windows car dans bon nombre de sociétés les environnement d'entreprise sont sous Windows, lobbying oblige, et pour développer nous n'avons d'autres choix que d'émuler un environnement linux.
 
Oui je n'aime pas windows car nous avons trop galéré en mise à jour d'applications suite aux évolutions des OS et des services packs jamais bien contrôlés et pas suffisamment d'information vers les SSII, même en prenant tous les partenariats possibles.
 
Alors nous avons abandonné les WinCE et compagnie pour venir sur des systèmes embarqués sous linux.
 
Ne chercher pas de polémiques inutiles, ça n'aide en rien ma problématique, et je trouve déplacé de venir me justifier de mes commentaires pour avoir le droit de glaner de votre part des informations que je ne maitrise pas encore.
Les connaissances que vous avez ne vous positionne en aucune manière en un juge de mes remarques et soit vous êtes ici pour aider, auquel cas, nous continuons à dialoguer, ou sinon, j'attendrai qu'un aidant pragmatique veuille bien me répondre.
 
Donc, pour en revenir à vos infos :
- atexit ne m'aidera pas à trapper un "exception fault", si je comprend bien son fonctionnement.
- _Exit, effectivement, j'avais déjà essayé.
- reste le signal 11 pour "exception fault" que je ne sais pas trapper, même après avoir lu et vu des exemples.
 
Comment puis-je faire ?

C'est toi qui parle de lobbying sans autre argumentaire, qui parle d'être fou pour être sous windows alors que la plupart d'entre nous s'en trouvent très satisfaits, la polémique, c'est avec tes piques régulières que tu la lances, et ce ne sont pas les autres intervenants ici. Eux te demandaient juste sous quel environnement tu travaille. Fin de la paranthèse.
 
Edit : pour apporter ma pierre à l'édifice, pour les MFC, Microsoft (oui, justement) proposait une solution de gestion d'exceptions à base de macros en C, je crois qu'on peut retrouver une lib similaire, mais évidemment, ca ne fait pas de miracle. le système lui-même n'en lève pas parce que ce n'est pas standardisé.

Une idée du nom de la lib, d'une description ?

En cherchant un peu grâce à notre ami commun google, on trouve pas mal de tentatives de proposer des exceptions en C, mais globalement, on voit les solutions se diviser en deux catégories au moins :
- D'une part, des implémentations à base de variables globales d'état (le throw modifie cet état, le catch le vérifie) qui pose quelques soucis si jamais tu fais du multi thread (à moins que tu aies un mécanisme pour passer ce contexte en thread local storage, mais c'était absent de s implémentations que j'ai croisées à l'instant)
- D'autre part, des implémentations qui reposent sur les setjmp/longjmp qui peuvent être intéressantes à essayer, comme par exemple ce qui est décrit ici
 
Cela dit, tu noteras que, dans tous les cas, le système ne t'enverra pas lui-même d'exception. Ce sera à toi de tester les codes d'erreurs et de lever manuellement l'exception, que ce soit pour tes appels systèmes ou pour tes appels à d'éventuels bibliothèques externes.
 
Après, si ca te suffit de ne plus devoir t'inquiéter que des bordures de ton application, ces solutions peuvent peut-être te convenir.

C'est sur que l'on pouvait deviner que ton problème concernait de l'embarqué, qui a des contraintes spécifiques (pas de core, vu qu'il y a pas d'espace de stockage pour ça à priori). J'avais probablement pas bien nettoyé ma boule de cristal.
Il te faut l'avis d'un spécialiste de l'embarqué, et tu devrais faire figurer cela dans le titre de ton topic.
Comme tu utilises gcc, tu peux utiliser la fonction spécifique backtrace() et la technique décrite par le 3e intervenant ici (l'article qu'il donne en lien est a lire aussi) http://stackoverflow.com/questions [...] pp-crashes
Mais bon, si tu compiles sous windows, en émulant linux, pour une plateforme embarquée, il y a fort a parier que l'émulation des signaux soit loin d'être parfaite, et donc rien ne garantit que les techniques indiquées marchent. Rien que pour l'émulation d'un trap de SIGUSR, avec un programme de 20 lignes en mode console DOS compilé sous digital mars, il y a des comportements aléatoires sous windows, alors...
A+,

Merci, donc préférable de monter une machine en ubuntu ou autre ?
 
Comment se garantir de la production possible ou non des signaux ?

S'il est simplement sous cygwin pour faire du cross compiling, c'est pas gênant de reposer sur des signaux, tant qu'il n'attend pas que son programme soit portable sous windows.

Comme je le dis juste au-dessus, ca dépend de ce que tu fais de ton programme, c'est pas nécessaire d'avoir une machine proche de l'environnement d'exécution pour développer sur de l'embarqué, fort heureusement.