Problème de jardinage mémoire sous Linux

Version imprimable

31/07/2006, 15h41
Mike29

Problème de jardinage mémoire sous Linux

Bonjour à tous,

C'est la première fois que je laisse un message sur ce type de forum et je m'excuse d'avance des manques de précisions éventuels. Je vais essayer de donner le plus de détails.

Je travaille actuellement sur un code C ANSI auto-généré à partir d'un modèle Simulink et je veux le faire tourner sous Linux. Je l'ai compilé avec gcc et j'ai créée un exécutable de test pour alimenter l'autocode.

Tout paraissait fonctionner, mais les calculs étaient faux (la plupart des résultats étant "nan" Not a Number).

Au debug (GDB, printf...), je me suis rendu compte que certains calculs ne se faisaient pas bien.

Le bug qui revient plusieurs fois est le suivant :
(NoLigne) variable = valeurINIT;
(NoLigne+1) variable = expressionDeCalcul(parametre1,
parametre2,
parametre3...);

- expressionDeCalcul est une expression littérale qui fait en général
une simple combinaison de multiplication, addition, soustraction,
division des paramètres...
- le type des paramètres et de la variable calculée est "double"
(pas de problème de type en gros)
- les paramètres ne sont pas à "nan" et il n'y a pas de division par 0,
de racine carré de nb négatif...
- Dans gdb, après l'exécution de "NoLigne", variable a la bonne valeur.
Après l'exécution de "Noligne+1" (qui succède directement l'exécution
de NoLigne), variable est à "nan".
Pourtant l'impression de l'expression littérale dans GDB
( p expressionDeCalcul ) me donne une bonne valeur.

Exemple :
variable = 0.0;
variable = (fytr+fytl)*(rx+(XCT-0.25)*ba)-(fxtr+fxtl)*(ry-YCT);

(gdb) p variable
$46 = -nan(0x8000000000000)
(gdb) p (fytr+fytl)*(rx+(XCT-0.25)*ba)-(fxtr+fxtl)*(ry-YCT)
$47 = 0.93050826743603743

Ce sont des calculs vraiment simples, et des calculs similaires en tous points ne buge pas. J'en conclu que ce n'est pas un problème de codage (enfin pas directement)....

Et c'est là que je suis sec et que je fais appel à vous.

Si vous avez des pistes de recherches (ex : causes de jardinage mémoire sous Linux avec code C compilé) ou si vous avez déjà rencontré ce type de bug, çà m'interesserais beaucoup.

J'en serai très reconnaissant et la gratification spirituelle sera énorme.

Merci d'avance

Mickaël
31/07/2006, 15h57
Arnaud F.

Je ne vois pas trop le rapport avec Linux vu que ton problème concerne le langage C ( il y a un forum pour ça ;) )

Donc si au passage un modo a les droits de déplacer ce thread ;)

P.S: Bienvenue sur Developpez.com ! :D
( mon 900ième post, youpi :aie: )
31/07/2006, 16h37
gege2061

Citation:

Envoyé par buchs

Je ne vois pas trop le rapport avec Linux vu que ton problème concerne le langage C ( il y a un forum pour ça ;) )

C'est pas sûr mais dans un premier temps, je pense que c'est par là qu'il faut chercher !

@Mike29 : ça serait possible d'avoir un peu plus de code (le code C généré) ? tu as vérifié un par un les résultats intermédiaires du calcul ?

Citation:

C'est pas sûr mais dans un premier temps, je pense que c'est par là qu'il faut chercher !

En fait, le problème peut venir de Matlab avec un pb d'autocodage, de codage à la main (il y a des S-functions dans le modèle), de Linux...

Le topic pourrait presque être dupliqué dans les forum Matlab, C et Linux ;-)

Sinon les sources autocodées représentent en gros quelques Mégas, alors c'est difficile d'être exhaustif en donnant des bouts de code. De plus, je n'ai rien développé alors le debuggage est vraiment laborieux.

Je vous donne tout de même un exemple de d'autocode qui bug avec le prompt gdb.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /* Sum: '<S256>/Add1' incorporates: * Product: '<S256>/Product3' * Product: '<S256>/Product4' */ rtb_r64_temp3116 = simu_rrj_B.Sum1 * simu_rrj_B.Sum1 + simu_rrj_B.Sum2 * simu_rrj_B.Sum2; printf("avant sqrt : %f\n",rtb_r64_temp3116); /* Math: '<S256>/Math Function' */ if(rtb_r64_temp3116 < 0.0) { rtb_r64_temp3116 = -sqrt(-rtb_r64_temp3116); } else { toto_temp = sqrt(rtb_r64_temp3116); rtb_r64_temp3116 = toto_temp; } printf("après sqrt : %f\n",rtb_r64_temp3116);
Par rapport à l'autocode, j'ai rajouté des printf et une variable temporaire toto_temp.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 avant sqrt : 0.000000 3: &toto_temp = (double *) 0x838c9b0 2: toto_temp = 0 1: &rtb_r64_temp3116 = (real_T *) 0xbfe62ca8 (gdb) 3: &toto_temp = (double *) 0x838c9b0 2: toto_temp = 0 1: &rtb_r64_temp3116 = (real_T *) 0xbfe62ca8 (gdb) n 3: &toto_temp = (double *) 0x838c9b0 2: toto_temp = -nan(0x8000000000000) 1: &rtb_r64_temp3116 = (real_T *) 0xbfe62ca8 (gdb) x/8b &toto_temp 0x838c9b0 <toto_temp>: 0x00 0x00 0x00 0x00 0x00 0x00 0xf8 0xff (gdb) n 3: &toto_temp = (double *) 0x838c9b0 2: toto_temp = -nan(0x8000000000000) 1: &rtb_r64_temp3116 = (real_T *) 0xbfe62ca8 (gdb) après sqrt : nan 3: &toto_temp = (double *) 0x838c9b0 2: toto_temp = -nan(0x8000000000000) 1: &rtb_r64_temp3116 = (real_T *) 0xbfe62ca8 (gdb) x/8b &rtb_r64_temp3116 0xbfe62ca8: 0x00 0x00 0x00 0x00 0x00 0x00 0xf8 0xff

01/08/2006, 11h41
ciol2.6.12

je vais pas t'avancer, mais il me semble que le problème se situe là :
toto_temp = sqrt(rtb_r64_temp3116);

rtb_r64_temp3116 doit être négatif (d'où le nan), bien que >= 0.0 d'après le code. Peut être il y a t-il un problème à cause de l'imprécision sur les flottants.
en tout cas il serait intéressant que tu donnes la valeur de rtb_r64_temp3116 et le type de real_T (il doit y avoir un typedef machin real_T quelque part).
01/08/2006, 14h23
granquet

je crois qu'on peux oublier cette histoire d'imprecision sur les flotants ... il as dis que c'etait des doubles.

de plus;

Citation:

Envoyé par man sqrt

ERRORS
EDOM x is negative.
01/08/2006, 18h29
ciol2.6.12

> je crois qu'on peux oublier cette histoire d'imprecision sur les flotants ... il as dis que c'etait des doubles

et les doubles c'est pas des flottants ?

> de plus;
> Citation:
> man sqrt a écrit :
>> ERRORS
>> EDOM x is negative.

oui c'est bien ce que je suppose, faire un perror("erreur:") pour être sûr.
maintenant il faut savoir pourquoi x est négatif alors que la condition x < 0.0 n'est pas vraie. Je crois qu'avec les flottants il peut y avoir des problèmes mais mes compétences s'arrêtent là (peut être mettre un long double au lieu d'un double ? )
01/08/2006, 19h02
Mike29

Je viens de faire une nlle manip et çà semble avoir corriger le problème sur les quelques tests que j'ai pu réaliser.

En fait mon modèle Simulink contient des S-function qui ont été générées à l'origine avec S-Function Builder, interface Matlab qui facilite la génération des S-functions.

Quand j'ai compilé l'autocode avec les S-function, je ne les ai pas regénéré avec S-function builder.

La subtilité avec SFB est que l'on peut choisir d'inliner les SF dans l'autocode Simulink. En gros une S-function non-inlinée a la même interface que sous Simulink et une inlinée a un simple wrapper comme interface. Et les types de variables ne sont pas gérer de la même façon (différent include, différent typedef...)

Les SF que j'avais étaient inlinées, mais moi pour des problèmes de compilation j'ai du les désinliner. Mais j'ai oublier de les regénérer avec SFB avec l'option non-inlined.

Au final, mes S-function utilisaient des types de l'autocode (ceux des SF inlined), alors qu'elle devait utiliser des types Simulink (ceux des SF non-inlined).

Je ne sais pas si je suis très clair, mais en tout cas la gestion des types des variables devait être un peu foireuse du coup...

Je vous remercie du temps que vous avez passer sur ce bug de l'espace et je vous tiendrais au courant quand j'aurai analyser un peu plus profondément l'origine du problème.

++

Mickaël