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