Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ Bug indétectable via printf() / cout

Bug indétectable via printf() / cout

148 réponses
Avatar
AG
Bonjour =E0 tous,

Je travaille dans une =E9quipe de personnes pour lesquels le d=E9bugger
n'est pas l'outil qui tombe sous le sens lorsqu'il s'agit de trouver
les bugs des outils qu'ils ont d=E9velopp=E9.

Afin de les sensibiliser, je recherche un exemple de bug difficile
(voir impossible) a d=E9tecter via des printf()/cout qui n'afficheraient
que les contenus des variables. (Je me rends bien compte qu'on doit
pouvoir tout d=E9bugger avec printf()/cout, mais il faut parfois
afficher les adresses des variable (en plus de leur valeur), voir
parfois la m=E9moire =E0 certains endroits.)

Je voudrais construire un exemple simple (notions de C++ pas trop
compliqu=E9es) et court (un seul fichier, 100 lignes max) pour qu'on
puisse l'=E9tudier en un quart d'heure, mais le d=E9bugger en un temps
presque infini sans d=E9bugger.

Il est possible que l'exemple, puisqu'il y a un bug, d=E9pende de la
plateforme mais c'est un peu in=E9vitable.

L'id=E9al serait que le plantage ait lieu bien apr=E8s le bug...=E7a rajout=
e
du piment. Bref, vous voyez l'id=E9e quoi...

J'avais plusieurs pistes d'exploitation de bug:

Piste 1:
Boucle for d=E9croissante sur un entier non sign=E9 : for(size_t i =3D N;
0<=3D i; i--)

Piste 2:
comparaison de double : double x; ... ; x =3D=3D 0.0

Piste 3:
retour de malloc() non test=E9

Piste 4:
caract=E8re de fin de ligne non test=E9 (\0)

Mais jusque l=E0, je crains qu'il ne soit trop facile de d=E9tecter le
bug

J'ai donc ensuite pens=E9 aux r=E9f=E9rences. Mais ce code est encore un pe=
u
trop voyant. Dans le main(), on peut facilement se demander pourquoi
f1 et f2 sont des r=E9f=E9rences, ce qui met directement la puce =E0
l'oreille. Peut =EAtre trouvez vous ce code bien trop compliqu=E9, ou
auriez vous en t=EAte un mani=E8re de "l'am=E9liorer" :-)

A bon entendeur salut.

AG.




#include <iostream>

using namespace std;

#define BUFFER_LENGTH 10

template<int N, class T>
class fifo_circular
{
private:
T * position;
size_t pos_offset;
T buffer[N];

public:
fifo_circular() { pos_offset =3D N-1; position =3D buffer + pos_offset;
for(int i=3D0;i<N;i++) buffer[i]=3DT(0);};

T step(T &input)
{
*position =3D input;

if(pos_offset>0) // ici il y aurait peut =EAtre moyen de glisser le
bug de la piste 1
pos_offset--;
else
pos_offset =3D N-1;

position =3D buffer + pos_offset;
return *position;
};

template<int M, class U> friend ostream & operator<<(ostream & o,
const fifo_circular<M,U> &f);
};

template<int N, class T>
fifo_circular<N,T> & Init(T & value)
{
fifo_circular<N,T> & f =3D fifo_circular<N,T>(); // h=E9 h=E9 h=E9

for(size_t i =3D 0; i < N; i++)
f.step(value);
return f;
}

template<int M, class U>
ostream & operator<<(ostream & o, const fifo_circular<M,U> &f)
{
for(size_t i =3D 0; i < M; i++)
o << f.buffer[i] << " ";
return o;
}

int main(int argc, char * argv[])
{
int a =3D 1;
fifo_circular<5,int> & f1 =3D Init<5,int>(a); // ici, c'est un peu trop
voyant. On se demande pourquoi f1 est d=E9clar=E9 en tant que
r=E9f=E9rence...
a =3D 2;
fifo_circular<5,int> & f2 =3D Init<5,int>(a);

cout << "fifo f1: " << f1 << "\n";
cout << "fifo f2: " << f2 << "\n";

return 0;
}
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
4 5 6 7 8
Avatar
James Kanze
On Dec 1, 4:44 pm, AG wrote:
On Dec 1, 2:27 pm, James Kanze wrote:> Si on se t rouve avec une erreur qui n'est pas détectée par les
> tests unitaires,



Mais avant ça, comment trouver cette erreur ? -> débuggeur ou
ajout de nouveau code de débug...



Surtout, à partir des informations en provenance du client. La
première chose à faire, toujours, c'est de pouvoir reproduire
l'erreur (ce qui n'est pas toujours évident, selon le type
d'application). Une fois reproduite, on écrit un test qui le
révèle systèmatiquement, d'une part d'être sûr par la suite
qu'on l'a corrigée, et de l'autres pour les besoins de la
regression. Ça, c'est avant de commencer à chercher d'où elle
vient.

Ensuite, selon les personnes, on pourrait se servir du
déboggueur pour essayer d'isoler le composant en cause. Dans la
plupart des applications sur lesquelles j'ai travaillé dans la
passée, en revanche, une bonne analyse des fichiers de log
suffisait.

--
James Kanze
Avatar
James Kanze
On Dec 1, 2:29 pm, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe de
discussion :




> On Dec 1, 10:19 am, "Senhon" wrote:
>> "Fabien LE LEZ" a écrit dans le
>> message de groupe de discussion :
>>
>> > On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG :



> À un moment ou à autre, il faut bien que tu précises à VS quels
> fichiers sont dans le projet, etc.



He bien, non ! Les déclarations des fichiers dans les projets sont
automatisés.



Alors, il est vraiment génial, parce qu'il peut lire dans ma
tête. (Je peux dire à GNU make de prendre tous les .cc dans un
répertoire -- c'est une chose à éviter.)

> Travail qui est bien plus facile sous vim que avec la souris.



C'est ce que je disais, tu essaies de faire comme avec vim.



Ou d'autre chose. Ce qui est certain, c'est que pendant que tu
saisis le code, il ne faut pas éloigner les mains de la position
de base sur le clavier, au prix d'une perte de productivité
importante.

Le parallèle programmation C et programmation C++ me parait
fort à propos. Utiliser VS comme vim n'a en soit pas
d'intérêt.



Dans le mesure où on ne le peut pas, parce qu'il n'en a pas les
fonctionalités de base qu'il faut.

Par contre j'ai compris que dans ton cas actuel il ne soit pas
simple d'appréhender tout le potentiel de VS. Pour ce faire
il faudrait être l'initiateur du projet. Et encore du premier
coup cela me semble très improbable, il faudra se casser la
tête, faire plusieurs tentatives, pour parvenir à un résultat
significatif.



Les macros de VS c'est du VB, avec l'aide des "objet
automation", tu programmes ton outil comme tu le souhaites.



Et les macros de vim, c'est tout ce qui m'offre le système. Y
compris du code que j'ai écris en C++, des scripts de shell, et
que sais-je.

--
James Kanze
Avatar
Michael DOUBEZ
Fabien LE LEZ a écrit :
On Tue, 1 Dec 2009 02:39:41 -0800 (PST), Michael Doubez
:

Et je ne vois pas la relation avec la recursion, programmer un outil
de programmation est un processus itératif.



L'idée de programmer un outil pour pouvoir programmer, est récursive.



Ca me parait plutôt itératif dans la mesure ou une version antérieur
permet de générer une version suivante mais on ne reviens pas à la
version précédente (sauf quand on upgrade de vista a XP :o).

--
Michael
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 1, 2:38 pm, "Senhon" wrote:
"Marc Boyer" a écrit dans le message
de
groupe de discussion : hf3950$
> Le 01-12-2009, Senhon a écrit :



Lorsque l'on est dans l'IDE je ne voit pas comment on peut
déterminer si une fonctionnalité est à attribuer à une partie
ou à une autre. L'avantage de l'IDE : c'est d'être à la fois
, et éditeur, et compilateur, et debugger.



C'est aussi le désavantage. On a un outil qui fait moyenement
tout, mais rien très bien. (Je ne crois pas qu'il faut que ce
soit le cas, mais dans la pratique, ou bien c'est le cas, ou
bien l'integration montre ses coutures.)



Peux-tu préciser de quel produit tu parles ?
Avatar
James Kanze
On Dec 2, 8:14 am, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe de
discussion :




> On Dec 1, 2:38 pm, "Senhon" wrote:
>> "Marc Boyer" a écrit
>> dans le message de groupe de discussion :
>> hf3950$
>> > Le 01-12-2009, Senhon a écrit :



>> Lorsque l'on est dans l'IDE je ne voit pas comment on peut
>> déterminer si une fonctionnalité est à attribuer à une partie
>> ou à une autre. L'avantage de l'IDE : c'est d'être à la fois
>> , et éditeur, et compilateur, et debugger.



> C'est aussi le désavantage. On a un outil qui fait moyenement
> tout, mais rien très bien. (Je ne crois pas qu'il faut que ce
> soit le cas, mais dans la pratique, ou bien c'est le cas, ou
> bien l'integration montre ses coutures.)



Peux-tu préciser de quel produit tu parles ?



Pratiquement tous les IDE. Les bons éditeurs, ce sont les
éditeurs, non des sous-produit d'un IDE. De même pour les bons
deboggueurs, etc. Or, ou bien, l'IDE integre son propre éditeur
(comme VS), et c'est moins bien que les éditeurs spécialisés, ou
bien, il integre un éditeur existant (Sun Studios, par exemple),
et l'integration est moins que parfait.

Je ne crois pas que ce soit quelque chose d'inévitable. Surtout
que les sources des éditeurs qu'integre Sun Studios sont
libres. Sun pourrait les modifier pour assurer une integration
complete -- à condition de mettre tout Sun Studios sous GPL, ce
que Sun n'est pas pret à faire. Sinon, Microsoft a bien des
ressources pour donner à l'éditeur de VS toutes les
fonctionalités de emacs ou de vim, sans utiliser les sources de
ces éditeurs. Mais il ne le fait pas, ne me démande pas
pourquoi.

--
James Kanze
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 1, 2:27 pm, Marc Boyer
wrote:
Le 01-12-2009, Senhon a écrit :




C'est surtout une fonctionalité de l'éditeur, je crois.



non de l'IDE.
Dans un "environnement de développement intégré", je ne vais pas m'enliser
dans une discussion pour différentier le debugger de l'éditeur.
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 1, 2:38 pm, "Senhon" wrote:
"Marc Boyer" a écrit dans le message
de
groupe de discussion : hf3950$
> Le 01-12-2009, Senhon a écrit :



Lorsque l'on est dans l'IDE je ne voit pas comment on peut
déterminer si une fonctionnalité est à attribuer à une partie
ou à une autre. L'avantage de l'IDE : c'est d'être à la fois
, et éditeur, et compilateur, et debugger.



C'est aussi le désavantage. On a un outil qui fait moyenement
tout, mais rien très bien. (Je ne crois pas qu'il faut que ce
soit le cas, mais dans la pratique, ou bien c'est le cas, ou
bien l'integration montre ses coutures.)



De quel outil es-tu en train de parler ?
Avatar
Michael Doubez
On 2 déc, 09:25, James Kanze wrote:
On Dec 2, 8:14 am, "Senhon" wrote:
> "James Kanze" a écrit dans le message de grou pe de
> discussion :
>
> > On Dec 1, 2:38 pm, "Senhon" wrote:
> >> "Marc Boyer" a écrit
> >> dans le message de groupe de discussion :
> >> hf3950$
> >> > Le 01-12-2009, Senhon a écrit :
> >> Lorsque l'on est dans l'IDE je ne voit pas comment on peut
> >> déterminer si une fonctionnalité est à attribuer à une parti e
> >> ou à une autre.  L'avantage de l'IDE  : c'est d'être à la fois
> >> , et éditeur, et compilateur, et debugger.
> > C'est aussi le désavantage. On a un outil qui fait moyenement
> > tout, mais rien très bien. (Je ne crois pas qu'il faut que ce
> > soit le cas, mais dans la pratique, ou bien c'est le cas, ou
> > bien l'integration montre ses coutures.)
> Peux-tu préciser de quel produit tu parles ?

Pratiquement tous les IDE. Les bons éditeurs, ce sont les
éditeurs, non des sous-produit d'un IDE. De même pour les bons
deboggueurs, etc. Or, ou bien, l'IDE integre son propre éditeur
(comme VS), et c'est moins bien que les éditeurs spécialisés, ou
bien, il integre un éditeur existant (Sun Studios, par exemple),
et l'integration est moins que parfait.



Je connais des personnes qui ne jurent que par eclipse. Je ne l'ai
essayé qu'une fois et il me paraissait prometteur mais je n'ai pas
pris le temps d'apprendre a m'en servir.

Et puis je me suis laissé dire qu'on pouvait intégrer vim dedans :)

--
Michael
Avatar
Senhon
"James Kanze" a écrit dans le message de groupe de
discussion :

On Dec 1, 2:29 pm, "Senhon" wrote:
"James Kanze" a écrit dans le message de groupe
de
discussion :




> On Dec 1, 10:19 am, "Senhon" wrote:
>> "Fabien LE LEZ" a écrit dans le
>> message de groupe de discussion :
>>
>> > On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG :



> À un moment ou à autre, il faut bien que tu précises à VS quels
> fichiers sont dans le projet, etc.



He bien, non ! Les déclarations des fichiers dans les projets sont
automatisés.



Alors, il est vraiment génial, parce qu'il peut lire dans ma
tête. (Je peux dire à GNU make de prendre tous les .cc dans un
répertoire -- c'est une chose à éviter.)



Nous sommes d'accord il est génial.
Il est possible grâce aux macros d'ajouter une souplesse difficilement
atteignable autrement.


> Travail qui est bien plus facile sous vim que avec la souris.



C'est ce que je disais, tu essaies de faire comme avec vim.



Ou d'autre chose. Ce qui est certain, c'est que pendant que tu
saisis le code, il ne faut pas éloigner les mains de la position
de base sur le clavier, au prix d'une perte de productivité
importante.

Le parallèle programmation C et programmation C++ me parait
fort à propos. Utiliser VS comme vim n'a en soit pas
d'intérêt.



Dans le mesure où on ne le peut pas, parce qu'il n'en a pas les
fonctionalités de base qu'il faut.



Pas compris, de quels fonctionnalités parles-tu ?


Par contre j'ai compris que dans ton cas actuel il ne soit pas
simple d'appréhender tout le potentiel de VS. Pour ce faire
il faudrait être l'initiateur du projet. Et encore du premier
coup cela me semble très improbable, il faudra se casser la
tête, faire plusieurs tentatives, pour parvenir à un résultat
significatif.



Les macros de VS c'est du VB, avec l'aide des "objet
automation", tu programmes ton outil comme tu le souhaites.



Et les macros de vim, c'est tout ce qui m'offre le système. Y
compris du code que j'ai écris en C++, des scripts de shell, et
que sais-je.



Bah, si tu le dis que tu peux faire aussi bien qu'un IDE.
Oui, c'est théoriquement faisable, d'ailleurs VS, je ne sais pas en quoi il
écrit, mais, il a été écrit, par je ne sais combien de développeurs, tester
pas je ne sais combien d'équipes qualification.
De ton coté tu as décidé que ce n'était un produit pour toi, soit, c'est ton
droit le plus absolu.
Avatar
Marc Boyer
Le 01-12-2009, James Kanze a écrit :
On Dec 1, 2:27 pm, Marc Boyer
wrote:
Oui, c'est super utile, mais c'est une fonctionnalité d'IDE,
pas de débogueur.



C'est surtout une fonctionalité de l'éditeur, je crois.



Oui et non.
Ca suppose une connaissance sémantique du langage, et à mon
sens, un éditeur ne connait ni C ni C++.
L'intégration (IDE) passe par la possibilité qu'à l'éditeur
à aller discuter avec un analyseur de code.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
4 5 6 7 8