Re: Question de c/c++

> >
> > 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 (&param_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 (&param_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.
> >>
> >>
>
>