Bug avec un printf()

[invite8a7e1f83]

Bonjour,

C'est une erreur assez spectaculaire.

J'ai un algo qui tourne (trop long pour le mettre sur le topic). A la fin de cet algo je fais un

printf("mavaleur : %f\n, mavaleur);

Jusqu'ici tout se passe bien.

Mais quand j'enlève ce printf, plus rien ne fonctionne et l'algo ne fait pas le travail demandé !

Je me suis dit que c'est un problème de temps, j'ai donc remplacé le printf par un sleep(0.5) ou même 2 boules for imbriqués. Rien n'y fait seul avec le printf l'algo fonctionne.

De plus, si j'écris

printf("mavaleur : %f, mavaleur);

ça ne marche pas ! il faut en plus rajouter le

\n

sans le \n ça fonctionne pas non plus

Ca fonctionne si je fais uniquement ça aussi :

printf("\n");

Je n'ai jamais vu ça ..

Quelqu'un aurai des idées ?

Merci
-----

[invite7a96054d]

Bonjour,

j'ai une bonne et une mauvaise nouvelle. La bonne est que printf n'est pas bugué, la mauvaise est que ton algo l'est.
Ce genre de symptôme est typique d'un heisenbug. Comme il s'agit d'un programme en C j'essayerais :

* de ne pas ignorer les warnings émis par le compilo
* de rajouter certaines options de compilation pour afficher des warnings supplémentaires
* d'utiliser valgrind comme outil de diagnostique rapide
* de faire tourner l'appli en mode debug et de bien vérifier les accès mémoire (variable non initialisée, tableau accédé en dehors des limites, etc) sur lesquels valgrind aura râlé.

[polo974]

les "pinces à linges" vont toujours par 2...

[invite8a7e1f83]

les "pinces à linges" vont toujours par 2...

??????????

[A voir en vidéo sur Futura]

[invite8a7e1f83]

Bonjour,

j'ai une bonne et une mauvaise nouvelle. La bonne est que printf n'est pas bugué, la mauvaise est que ton algo l'est.
Ce genre de symptôme est typique d'un heisenbug. Comme il s'agit d'un programme en C j'essayerais :

* de ne pas ignorer les warnings émis par le compilo
* de rajouter certaines options de compilation pour afficher des warnings supplémentaires
* d'utiliser valgrind comme outil de diagnostique rapide
* de faire tourner l'appli en mode debug et de bien vérifier les accès mémoire (variable non initialisée, tableau accédé en dehors des limites, etc) sur lesquels valgrind aura râlé.

J'ai trouvé ce matin mon problème.

En fait, j'utilisais avant des clock() qui calculais un temps si le clock-1 était différent du clock

En enlevant printf, le clock-1 était = au clock et du coup je calculais ma valeur et l'algo ne fonctionnais pas.

Je dois trouver un exemple de timer sur une beaglebone et je n'y arrive pas ...

[inviteb9f49292]

le coup du "\n" qui influe me fait furieusement penser que tu as oublié (ou tu ignores) que très souvent "printf" est "bufferisé", ce n'est pas parceque tu sors du "printf" que tu as effectivement écrit sur ton pérphérique. L'écriture est effective lorsque:
- le tampon est plein
- sur appel explicite de "fflush"
- sur émission de certains caractères particulier dont "\n" fait parti par défaut.

[invite8a7e1f83]

Merci, je ne savais pas.

[invite895675d5]

J'ai trouvé ce matin mon problème.

En fait, j'utilisais avant des clock() qui calculais un temps si le clock-1 était différent du clock

En enlevant printf, le clock-1 était = au clock et du coup je calculais ma valeur et l'algo ne fonctionnais pas.

Je dois trouver un exemple de timer sur une beaglebone et je n'y arrive pas ...

La première idée qui me viens, c'est que tu utilises mal clock() et donc que tu calcules un peu au petit bonheur la chance (le fait qu'une légère modif autour du printf fasse tout partir en vrille le confirme). Peux-tu poster, la partie du code qui gère le déclenchement de ton calcul ?

[danyvio]

Bonjour,

C'est une erreur assez spectaculaire.

J'ai un algo qui tourne (trop long pour le mettre sur le topic). A la fin de cet algo je fais un

printf("mavaleur : %f\n, mavaleur);

Jusqu'ici tout se passe bien.

ça m'étonnerait que ça marche bien, car comme le dit polo974, les pinces à linges fonctionnent par 2....
Relis bien ta ligne
cot cot cot codec...