c'est la conclusion à laquelle j'avais aboutie : il y avait un endroit
par où ca passait où la désallocation n'était pas faite. Ca expliquait
pourquoi ca ne marchait pas avec certaines valeurs, je suppose avec un
test pour éviter les divisions par 0.
Le 14/01/2025 à 18:53, Patrick Dupre a écrit :
> Bonsoir,
>
> Je crois que j'ai compris.
> Il devait y avoir une mauvaise desallocation memoire parce qu'il y avait
> un if pour le cas le calcul n'etait pas effectue.
> Cela n'avait pas ete teste correctement car la condition n'etait
> pas satisfaite tant que je ne modifiais pas l'un des parametres de facon
> externe.
> C'est ce qui m'a induit en erreur car j'ai fait une correlation abusive.
>
> Desole pour le bruit. Il a fallu 24h pour resoudre le probleme.
>
> Merci a toute vos suggestions qui m'ont incite a revoir mon code et
> mes allocations.
>
>
>
>> Sent: Tuesday, January 14, 2025 at 6:33 PM
>> From: "Yves Gufflet" <yves.gufflet@???>
>> To: guilde@???
>> Subject: Re: Question de c/c++
>>
>> c possible d'avoir les codes sources des 2 fonctions ?
>>
>> Le 14/01/2025 à 12:30, Patrick Dupre a écrit :
>>>> Sent: Tuesday, January 14, 2025 at 11:19 AM
>>>> From: "Yves Gufflet" <yves.gufflet@???>
>>>> To: guilde@???
>>>> Subject: Re: Question de c/c++
>>>>
>>>> Si c'est toi qui a écrit le code
>>>>
>>>> call_ode_BAP_2
>>>>
>>>> Il faudrait voir pourquoi tu fais un malloc dedans
>>> Je n'ai pas le choix,
>>> Il faut que je m'alloue des variables de grandes tailles.
>>> Je fais les dealloc correctement est systematiquement.
>>> Cela ce passe tres bien: pas de fuites.
>>> Je pense que c'est les allocations faites par numerical recipes ensuite
>>> ou il y a un probleme.
>>>
>>>
>>>> Le 14/01/2025 à 10:49, Patrick Dupre a écrit :
>>>>>> >
>>>>>> > Normalement cette structure est declaree en constante, mais je dois
>>>>>> la "forcer".
>>>>>> > Il n'y a pas de complainte du compilateur (gcc ou clang).
>>>>>>
>>>>>> personnellement je soupconnerais que l'utilisation forcée soit l'origine
>>>>>> du problème.
>>>>>>
>>>>>> si le compilateur ne se plaint pas c'est possiblement qu'il y a des
>>>>>> options pour qu'il omette de se plaindre en évitant des vérifications.
>>>>> J'ai
>>>>> extern double ode_BAP_impact_2 (const double, const cont_impact_struct *const) ;
>>>>> avec option
>>>>> OPT_CC=-O3 -Wall -Werror=implicit-function-declaration -mtune=native
>>>>>
>>>>> C'est pourquoi je fais:
>>>>>
>>>>> double ode_BAP_impact_2 (const double impact, const cont_impact_struct *const param_int) {
>>>>> BAP_struct_I param_doublet ;
>>>>> memcpy (¶m_doublet, param_int -> param, sizeof (BAP_struct_I)) ;
>>>>> const double tmp = param_int -> Rabi_0 * exp (-sqr (impact / param_int -> waist)) ;
>>>>> param_doublet.Rabi_0 = tmp ;
>>>>> call_ode_BAP_2 (¶m_doublet, param_int -> tolerance) ;
>>>>>
>>>>>> si ca passe au niveau du compilo mais qu'on force le comportement, il
>>>>>> est bien possible qu'à l'exécution ca pose des soucis.
>>>>>>
>>>>>> Sinon la fonction : call_ode_BAP_2, elle vient d'où ? c du code perso ou
>>>>>> ca vient d'une lib ?
>>>>> Oui c'est du code perso, il fau bien que je construise mon code.
>>>>> Tout ce passe correctement tant que je ne fais pas
>>>>> param_doublet.Rabi_0 = tmp ; (param_doublet.Rabi_0 = 1e-8 ne cree pas de probleme, mais le calcul est faux) ;
>>>>>
>>>>>
>>>>> Est-ce que passer en
>>>>> extern double ode_BAP_impact_2 (const double, cont_impact_struct *const) ;
>>>>> extern Thr_level_rho_struct call_ode_BAP_2 (BAP_struct_I *const, const double) ;
>>>>>
>>>>> ou
>>>>> extern double ode_BAP_impact_2 (const double, const cont_impact_struct *const) ;
>>>>> extern Thr_level_rho_struct call_ode_BAP_2 (const BAP_struct_I *const, const double) ;
>>>>>
>>>>> Changerait les choses
>>>>>
>>>>>
>>>>>> Le 14/01/2025 à 10:14, Patrick Dupre a écrit :
>>>>>>> Merci Edgar,
>>>>>>>
>>>>>>> J'ai fait la meme analyse.
>>>>>>> Tout ce que tu dis me semble correct.
>>>>>>> Pour la variable
>>>>>>> BAP_struct_I param_doublet ;
>>>>>>> que je soupconne probalement a tort, elle doit se desalloue automatique
>>>>>>> forcer avec un free (&) ne resout rien.
>>>>>>> C'est comme si il y avait dans les routines appellees par call_ode_BAP_2
>>>>>>> des variables qui ne sont pas desallouees correctement
>>>>>>> uniquement lorsque j'affecte
>>>>>>> param_doublet
>>>>>>> dans la boucle d'integration.
>>>>>>> si je ne la touche pas, il n'y a pas de fuite memoire, mais le calcul est faux.
>>>>>>>
>>>>>>> En utilisant standard, l'integrale porte sur une seule variable (x), et tout se passe bien,
>>>>>>> Dans mon cas, lorsque j'integre sur x, je dois aussi modifier une des variables (parametres)
>>>>>>> de la structure utilsee par GSL.
>>>>>>> Normalement cette structure est declaree en constante, mais je dois la "forcer".
>>>>>>> Il n'y a pas de complainte du compilateur (gcc ou clang).
>>>>>>> C'est comme si le fait de modifier cette structure contraint le programme a ne
>>>>>>> pas resalloue.
>>>>>>>
>>>>>>> Comment est-ce que je peux savoir quelle est la variable qui n'est pas desallouee en sortie
>>>>>>> d'integration ?
>>>>>>> L'espace utilise par la routine d'integration est desalloue correctemment.
>>>>>>> Je pense que c'est une zone memoire de Numerical recipes (en C++ mais non standard) qui n'est pas desallouee
>>>>>>> correctement.
>>>>>>> Je peux regarder le code une fois que j'ai identifie la variable fautive.
>>>>>>>
>>>>>>> Merci d'avance.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Bonjour !
>>>>>>>>
>>>>>>>> Patrick Dupré a écrit :
>>>>>>>>> j'ai des fuites memoire que je parviens pas a controller.
>>>>>>>> Ah... problème facile à rencontrer en C...
>>>>>>>>
>>>>>>>>> Tout se passe "normalement" si je fais param_doublet.Rabi_0 = 1e-8 ;
>>>>>>>>> [...] Si la variable est une constante, soit il n'y a pas
>>>>>>>>> d'allocationb intempestive, soit la desallocation se fait
>>>>>>>>> correctement.
>>>>>>>> Je n'ai rien compris à ces explications...
>>>>>>>>
>>>>>>>>> Je ne vois pas comment forcer la desallocation qui devrait etre
>>>>>>>>> automatique.
>>>>>>>> En appelant free(). Pourquoi elle devrait être automatique ? Si je crois
>>>>>>>> ce que dit Valgrind, dans la pile d'appels tu as
>>>>>>>>
>>>>>>>> gsl_integration_cquad() -> ode_BAP_impact_2()
>>>>>>>> -> call_ode_BAP_2() -> malloc()
>>>>>>>>
>>>>>>>> De ce que je comprends :
>>>>>>>>
>>>>>>>> * gsl_integration_cquad() appelle en boucle ode_BAP_impact_2() pour
>>>>>>>> évaluer la fonction à intégrer pour différentes valeurs de la
>>>>>>>> variable indépendante `impact' ;
>>>>>>>>
>>>>>>>> * ode_BAP_impact_2() appelle une fois call_ode_BAP_2() pour résoudre
>>>>>>>> un système d'équations ;
>>>>>>>>
>>>>>>>> * call_ode_BAP_2() appelle malloc() pour... je ne sais pas.
>>>>>>>>
>>>>>>>> Si j'ai bien compris, la mission de call_ode_BAP_2() est juste de
>>>>>>>> résoudre un système d'équations, pas d'allouer de la mémoire et la
>>>>>>>> donner à l'appelant. Si cette fonction appelle malloc(), c'est donc pour
>>>>>>>> ses propres besoins, et donc elle est responsable de libérer cette
>>>>>>>> mémoire avec free(), ce qu'elle ne fait visiblement pas (ou pas
>>>>>>>> toujours).
>>>>>>>>
>>>>>>>> À+,
>>>>>>>>
>>>>>>>> Edgar.
>>>>>>>>
>>>>>>>>
>>
