Si c'est toi qui a écrit le code
call_ode_BAP_2
Il faudrait voir pourquoi tu fais un malloc dedans
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.
>>>>
>>>>
>>
