assert

"Pierre Maurette" <mmaauurreetttteeppiieerrrree@wwaannaaddoooo.ffrr> writes:

| > "Pierre Maurette" <mmaauurreetttteeppiieerrrree@wwaannaaddoooo.ffrr> writes:
| [...]
| >> Ne peut-on pas laisser du code de déboguage dans une release ? Je veux
| >> dire si un assert ne pose pas de problème de performance. A ce
| >> moment-là, même si la condition assert-ée n'est pas censée survenir,
| >> il peut être utile d'être modeste et de préférer "au cas où" un
| >> comportement prévisible (abort()) et un message relativement explicite
| >> que le client pourra remonter.
| >
| > Un peu comme Ariane V ? ;-p
| Plus sérieusement que réponse précédente : j'ai fait un peu
| d'automatisme industriel (pas du C++, ni même du C). Les normes de
| sécurité imposent des redondances, jusqu'au matériel.

Je sais bien. Cette année, j'ai vu un logiciel téléphonique -- qu'on
arrête que pendant 2 heures tous les 25 ans -- dont le but principal
est de vérifier que les données écrites en mémoires sont bien celles
qui s'y trouvent...

Ma remarque concerne plutôt côté paradoxal de la chose. Dans le cas de
Ariane V, c'est même encore plus vicieux parce que le module ne
servait strictement à rien.

-- Gaby

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

Je ne comprends pas. Tu lui conseillerais de mettre un bouet de
sauvetage quand il s'amuse dans une piscine et qu'il l'enlève quand il
s'en va en mer ?

Là, en l'occurence, c'est pas une bouée de sauvetage, c'est un maitre
nageur qui surveille avec un fusil et qui tire sur les gens qui ne
savent pas nager ...

Mais bon, de toutes façons, « proof by analogy is fraud » ... (je me
demande bien où j'ai pu entendre ça ?)

--
Matthieu

Andre Heinen <nospam@nospam.invalid> writes:

| Assert n'est donc à utiliser que pour le débogage, et jamais pour la
| détection d'erreurs susceptibles de se produire lors d'une utilisation
| normale du programme.

Je ne comprends pas. Tu lui conseillerais de mettre un bouet de
sauvetage quand il s'amuse dans une piscine et qu'il l'enlève quand il
s'en va en mer ?

On flotte mieux en mer, donc une bouée y est effectivement moins utile ;-)

--
Richard

Gabriel Dos Reis wrote:

[...]

Ma remarque concerne plutôt côté paradoxal de la chose. Dans
le cas de Ariane V, c'est même encore plus vicieux parce que
le module ne servait strictement à rien.

Mais le problème dans le cas de l'Ariane V se situait ailleurs.
Sans l'assert dans le logiciel, le programme aurait été
défectueux -- dans le cas de l'utilisation prevu (dans le Ariane
IV), l'assert servait bien, et était même nécessaire. Il
detectait non seulement des erreurs de logiciel, mais aussi des
défauts des capteurs. Sans les asserts, le logiciel n'aurait pas
fonctionné correctement dans l'Ariane IV, c-à-d le contexte pour
lequel il a été conçu. (On pourrait arguer que ce n'est pas une
bonne politique de compter sur les asserts pour le
fonctionnement correct du programme.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

In article <42b69f3d$0$32591$636a15ce@news.free.fr>,
nico <nospam@spam.fr> wrote:

kanze@gabi-soft.fr wrote:

Il ne faut jamais mettre des #ifdef à l'intérieur d'une
fonction. Ça rend la fonction complètement illisible. (En fait,
dans le code de production, j'interdis des #ifdef complètement.
Il y a des cas, dans les en-têtes et au niveau de portée du
fichier, où on pourrait en discuter. Mais je n'accepterais
jamais un #ifdef qui n'est pas à la portée du fichier.)

C'est curieux, c'est pourtant pratique pour écrire du code multiplatforme.
Le premier exemple qui me vient à l'esprit, c'est l'utilisation des
sockets : car ça se fait de la même façon sous windows et unix au détail
près que sous windows il faut appeler WSAStartup() au démarrage et
WSACleanUp() à l'arret.

Donc je vois bien un truc du genre (dans le .cpp)

[ du spagghetti ]

Tu ne t'en rends pas compte, mais tu es en train de donner raison a James.

Si tu veux faire du code portable ET lisible ET maintenable, il faut bien
plus isoler le code qui pose des problemes de portabilite !

Toujours, toujours, toujours pondre les abstractions qui vont bien, les
appeler systematiquement, et fournir les implementations concretes dependant
du systeme d'exploitation.

Si tu pars sur le type de code que tu cautionnes, la tentation est grande
de rajouter un #ifdef ici, un #ifdef la, et de terminer avec du code
completement illisible.

Meme si c'est du C, je conseille vivement de jeter un oeil a passwd.c
dans xlockmore pour bien voir jusqu'ou ca peut mener...

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis wrote:
|
| [...]
| > Ma remarque concerne plutôt côté paradoxal de la chose. Dans
| > le cas de Ariane V, c'est même encore plus vicieux parce que
| > le module ne servait strictement à rien.
|
| Mais le problème dans le cas de l'Ariane V se situait ailleurs.
| Sans l'assert dans le logiciel, le programme aurait été
| défectueux -- dans le cas de l'utilisation prevu (dans le Ariane
| IV), l'assert servait bien, et était même nécessaire. Il

Non. Ce logiciel, ainsi que l'assert qu'il contenait, n'avait aucune
utilité dans le vol Ariane V.

| detectait non seulement des erreurs de logiciel, mais aussi des
| défauts des capteurs. Sans les asserts, le logiciel n'aurait pas
| fonctionné correctement dans l'Ariane IV, c-à-d le contexte pour
| lequel il a été conçu.

Ah mais, j'ai pas dit Ariane IV. J'ai dit Ariane V.

-- Gaby

Gabriel Dos Reis wrote:

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis wrote:

| [...]
| > Ma remarque concerne plutôt côté paradoxal de la chose. Dans
| > le cas de Ariane V, c'est même encore plus vicieux parce que
| > le module ne servait strictement à rien.

| Mais le problème dans le cas de l'Ariane V se situait ailleurs.
| Sans l'assert dans le logiciel, le programme aurait été
| défectueux -- dans le cas de l'utilisation prevu (dans le Ariane
| IV), l'assert servait bien, et était même nécessaire. Il

Non. Ce logiciel, ainsi que l'assert qu'il contenait, n'avait
aucune utilité dans le vol Ariane V.

Je sais. Et c'est bien là le problème : ce logiciel était conçu
et développé pour l'Ariane IV. Où l'assert servait bien, et
était même nécessaire.

Si je renomme ma source C++ en .c, et le compile avec gcc,
est-ce la faute de gcc qu'il y a des erreurs de compilation ? Si
je prends un logiciel conçu pour un Ariane IV, et je l'installe
dans un Ariane V, est-ce sa faute à lui qu'il trouve que les
entrées ne sont pas dans la plague attendue, qu'il le considère
comme un défaut qui lui empèche de fonctionner correctement, et
qu'il detruit l'engin. (Parce qu'avec les entrées qu'il a eu
dans un Ariane IV, ça pourrait signifier seulement que les
capteurs ne marchaient pas bien, et que donc il n'était plus
capable de contrôler l'engin. Et qu'entre risquer de tomber dans
une foule quelque part, ou détruire l'engin tout de suite...

| detectait non seulement des erreurs de logiciel, mais aussi
| des défauts des capteurs. Sans les asserts, le logiciel
| n'aurait pas fonctionné correctement dans l'Ariane IV, c-à-d
| le contexte pour lequel il a été conçu.

Ah mais, j'ai pas dit Ariane IV. J'ai dit Ariane V.

Ah mais, le logiciel en question était bien celui de l'Ariane
IV.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr writes:

Je sais. Et c'est bien là le problème : ce logiciel était conçu
et développé pour l'Ariane IV. Où l'assert servait bien, et
était même nécessaire.

Il n'y a pas d'assert en cause. Au choix une exception (mais le nom
donne n'est pas une exception predefinie d'Ada) ou une interruption
(le nom est bon, mais le rapport parlait d'exception).

Il y a differents problemes. Parmis ceux dont je me souviens:

- on a reutilise un composant sans verifier que les nouvelles
conditions d'utilisation ne sortaient pas de la zone acceptable

- on a lance qqch sans faire de tests (alors que lors de la
decision precedente, la justification etait que des problemes
eventuels seraient detectes par les tests)

- on a laisse le malfonctionnement d'un composant dont l'utilite
etait terminee generer la destruction de la fusee

- on a laisse sortir d'un composant en mode production des infos
de debug (sur un bus servant normallement pour des donnees)

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

On Mon, 20 Jun 2005 14:58:52 +0000 (UTC), Marc Boyer

Il me semble pourtant que la première et la deuxième partie de la
phrase ont le même sens?

Non,

Heu... si.

tu distingues deux cas d'erreurs:

Oui, tout à fait.

- celles qui arrivent lors du débugage

J'ai voulu dire: les bugs.

- celles qui sont susceptibles de se produire en utilisation
normales

J'ai voulu dire: les problèmes qui ne sont pas dûs à une erreur dans
le programme, mais à un problème runtime tel que par exemple une
entrée incorrecte.

Si le code que tu produis est d'une telle qualité qu'il se divise
en ces deux classes, bravo.

Merci ;-) mais ce n'est pas une question de qualité de code (voir
ci-dessus).

Mais je suis moins confiant. Donc, laisser
des tests qui vérifient que le code reste dans un état cohérent,
même en mode release, je ne vois pas ce que ça a de choquant.

Mais moi non plus.

Pierre et Gaby ont eu la même réaction que toi: ça m'étonne. Ai-je
conseillé de retirer ces tests dans les versions release? Ai-je
conseillé d'utiliser assert() plutôt qu'un autre mécanisme?

J'ai juste voulu répondre à la question de l'OP, lui expliquer
convenablement le fonctionnement d'assert(), et attirer son attention
sur le fait que les assertions peuvent être retirées automatiquement à
la compilation. Et que par conséquent il vaut mieux éviter assert()
si on veut la certitude que le test sera toujours exécuté, même dans
les versions release, et quelles que soient les macros qui seront
définies lors de la compilation.

Je n'ai pas du tout voulu déconseiller la mise en place de tests
redondants qui aideront à détecter les derniers bugs lorsque le
programme sera mis en production.

--
André Heinen
Mon e-mail, encodé ROT13: n qbg urvara ng rhebcrnayvax qbg pbz
La FAQ: http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/

Jean-Marc Bourguet <jm@bourguet.org> writes:

| kanze@gabi-soft.fr writes:
|
| > Je sais. Et c'est bien là le problème : ce logiciel était conçu
| > et développé pour l'Ariane IV. Où l'assert servait bien, et
| > était même nécessaire.
|
| Il n'y a pas d'assert en cause. Au choix une exception (mais le nom
| donne n'est pas une exception predefinie d'Ada) ou une interruption
| (le nom est bon, mais le rapport parlait d'exception).

Oui, une exception -- mais je parlais d'assertion au sens abstrait du
terme, où on vérifie qu'un invariant tient.



Sur la base de la documentation et des données exhaustives
relatives à l'échec d'Ariane 501 qui ont été mises à la
disposition de la Commission, on a pu établir la séquence
suivante d'événements ainsi que leurs interdépendances et leurs
origines, depuis la destruction du lanceur jusqu'à la cause
principale en remontant dans le temps.

* Le lanceur a commencé à se désintégrer à environ H0 + 39
secondes sous l'effet de charges aérodynamiques élevées dues à
un angle d'attaque de plus de 20° qui a provoqué la séparation
des étages d'accélération à poudre de l'étage principal,
événement qui a déclenché à son tour le système
d'auto-destruction du lanceur ;

* cet angle d'attaque avait pour origine le braquage en butée des
tuyères des moteurs à propergols solides et du moteur principal
Vulcain ;

* le braquage des tuyères a été commandé par le logiciel du
calculateur de bord (OBC) agissant sur la base des données
transmises par le système de référence inertielle actif
(SRI2). A cet instant, une partie de ces données ne contenait
pas des données de vol proprement dites mais affichait un profil
de bit spécifique de la panne du calculateur du SRI 2 qui a été
interprété comme étant des données de vol ;

* la raison pour laquelle le SRI 2 actif n'a pas transmis des
données d'attitude correctes tient au fait que l'unité avait
déclaré une panne due à une exception logiciel ;

* l'OBC n'a pas pu basculer sur le SRI 1 de secours car cette
unité avait déjà cessé de fonctionner durant le précédent cycle
de données (période de 72 millisecondes) pour la même raison que
le SRI 2 ;

* l'exception logiciel interne du SRI s'est produite pendant une
conversion de données de représentation flottante à 64 bits en
valeurs entières à 16 bits. Le nombre en représentation
flottante qui a été converti avait une valeur qui était
supérieure à ce que pouvait exprimer un nombre entier à 16
bits. Il en est résulté une erreur d'opérande. Les instructions
de conversion de données (en code Ada) n'étaient pas protégées
contre le déclenchement d'une erreur d'opérande bien que
d'autres conversions de variables comparables présentes à la
même place dans le code aient été protégées ;

* l'erreur s'est produite dans une partie du logiciel qui n'assure
que l'alignement de la plate-forme inertielle à composants
liés. Ce module de logiciel calcule des résultats significatifs
avant le décollage seulement. Dès que le lanceur décolle, cette
fonction n'est plus d'aucune utilité ;

* La fonction d'alignement est active pendant 50 secondes après le
démarrage du mode vol des SRI qui se produit à H0 - 3 secondes
pour Ariane 5. En conséquence, lorsque le décollage a eu lieu,
cette fonction se poursuit pendant environ 40 secondes de
vol. Cette séquence est une exigence Ariane 4 mais n'est pas
demandé sur Ariane 5 ;

* l'erreur d'opérande s'est produite sous l'effet d'une valeur
élevée non prévue d'un résultat de la fonction d'alignement
interne appelé BH (Biais Horizontal) et lié à la vitesse
horizontale détectée par la plate-forme. Le calcul de cette
valeur sert d'indicateur pour la précision de l'alignement en
fonction du temps ;

* la valeur BH était nettement plus élevée que la valeur escomptée
car la première partie de la trajectoire d'Ariane 5 diffère de
celle d'Ariane 4, ce qui se traduit par des valeurs de vitesse
horizontale considérablement supérieures.


| Il y a differents problemes. Parmis ceux dont je me souviens:
|
| - on a reutilise un composant sans verifier que les nouvelles
| conditions d'utilisation ne sortaient pas de la zone acceptable
|
| - on a lance qqch sans faire de tests (alors que lors de la
| decision precedente, la justification etait que des problemes
| eventuels seraient detectes par les tests)
|
| - on a laisse le malfonctionnement d'un composant dont l'utilite
| etait terminee generer la destruction de la fusee
|
| - on a laisse sortir d'un composant en mode production des infos
| de debug (sur un bus servant normallement pour des donnees)


Bien que la source de l'erreur d'opérande ait été identifiée,
elle n'est pas en soi la cause de l'échec de la mission. La
spécification relative au mécanisme de traitement des exceptions
a également contribué à la défaillance. En cas d'exception quelle
qu'elle soit, la spécification système précise que la défaillance
doit être indiquée sur le bus de données, que son contexte doit
être enregistré dans une mémoire EEPROM (qui a été récupérée et
lue à l'issue du vol Ariane 501) et que le processeur du SRI doit
être arrêté.

C'est la décision d'arrêter le fonctionnement du processeur qui
s'est finalement révélée fatale. Un redémarrage est impossible
car le calcul de l'attitude est trop difficile pour être refait
après l'arrêt du processeur, de sorte que le système de
référence inertielle devient alors inutile. La raison qui
sous-tend cette procédure draconienne tient à la philosophie
adoptée par le programme Ariane, qui consiste à ne prendre en
compte que les défaillances aléatoires de matériels. Dans cette
optique, les mécanismes de traitement des exceptions ou des
erreurs sont conçus pour faire face à une défaillance aléatoire
de matériel, qui peut être efficacement prise en charge par un
système de secours.

Bien que la défaillance ait été provoquée par une erreur de
conception de logiciel à caractère systématique, il est possible
d'introduire des mécanismes pour atténuer ce type de
problème. Par exemple, les calculateurs présents dans les SRI
auraient pu continuer de fournir leurs meilleures estimations
des informations d'attitude requises. Il est préoccupant de
constater qu'une exception de logiciel puisse être autorisée,
voire requise pour provoquer l'arrêt d'un processeur alors que
celui-ci commande des équipements critiques pour la mission. De
fait, la perte d'une fonction logicielle correcte présente un
risque car c'est le même logiciel qu'utilisent les deux unités
SRI. Dans le cas d'Ariane 501, cela s'est traduit par la mise
hors circuit de deux équipements critiques ne présentant pas de
défaillance.


http://www-rocq.inria.fr/qui/Philippe.Deschamp/divers/ariane_501.html

-- Gaby