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.
>>>>>>
>>>>>>
>>
