Non,
Normalement j'utilise memcpy
Mais j'ai essaye memmove pour voir si cela changeait quelque chose.
IL faudrait que j'arrive a voir quelle est la zone memoire qui n'est as desalloue
correctement.
===========================================================================
Patrick DUPRÉ | | email: pdupre@???
===========================================================================
> Sent: Tuesday, January 14, 2025 at 8:40 AM
> From: "Yves Gufflet" <yves.gufflet@???>
> To: guilde@???
> Subject: Re: Question de c/c++
>
> bonjour,
>
> pourquoi utiliser memmove plutot que memcpy ?
>
> apparemment memmove est capable de gérer des chevauchement de données.
>
> et elle doit utiliser un buffer temporaire pour le faire.
>
> peut etre que ca vient de là ?
>
>
>
> Le 13/01/2025 à 23:55, Patrick Dupre a écrit :
> > Bonsoir,
> >
> > Une question que m'echappe totalement.
> > Peut-etre pour Edgar !
> >
> > Dans la routine suivante tout se passe bien SAUF que j'ai des fuites memoire que je
> > parviens pas a controller.
> >
> > Cette function est appelee par une function d'integration de GSL.
> > La function call_ode_BAP_2 appelle une stucture de numerical recipes III pour
> > resoudre un systeme d'equations.
> > Tout se passe "normalement" si je fais
> > param_doublet.Rabi_0 = 1e-8 ; // par exemple.
> > Mais si j'affecte la variable, le calcule est correct (mais pas si je fais = 1e-8 evidemment).
> > Si j'interprete correctement ce que je vois, a partir du moment ou
> > j'affecte une variable qui va etre utilisee par cal_ode_BAP_2, il y a une duplication a chaque appel de
> > la memoire de calcul et cela diverge rapidement.
> > Si la variable est une constante, soit il n'y a pas d'allocationb intempestive, soit
> > la desallocation se fait correctement.
> >
> > Lorsque j'ai une fuite
> > valgrind me signale
> >
> > ==83464== 6,291,648 (192 direct, 6,291,456 indirect) bytes in 6 blocks are definitely lost in loss record 47 of 47
> > ==83464== at 0x4843866: malloc (vg_replace_malloc.c:446)
> > ==83464== by 0x4C9119A: call_ode_BAP_2 (in /home/pdupre/mylib/libODE_BAP_2.so.1.0)
> > ==83464== by 0x4C915B7: ode_BAP_impact_2 (in /home/pdupre/mylib/libODE_BAP_2.so.1.0)
> > ==83464== by 0x4A31973: gsl_integration_cquad (cquad.c:236)
> > ==83464== by 0x42CA23: Impact_integration_ode_BAP_2 (in /home/pdupre/Spectroscopy/Dressed/Density_Matrix/Density_matrix)
> > ==83464== by 0x403B93: main (in /home/pdupre/Spectroscopy/Dressed/Density_Matrix/Density_matrix)
> >
> > LEAK SUMMARY:
> > ==83464== definitely lost: 576 bytes in 18 blocks
> > ==83464== indirectly lost: 18,087,936 bytes in 69 blocks
> > ==83464== possibly lost: 786,432 bytes in 3 blocks
> > ==83464== still reachable: 2,489,432 bytes in 47 blocks
> > ==83464== suppressed: 0 bytes in 0 blocks
> > ==83464==
> > ==83464== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
> >
> > Je ne vois pas comment forcer la desallocation qui devrait etre automatique.
> > On dirait que c'est param_doublet qui n'est pas libere (mais c'est etrange)
> > Est-ce qu'il y a un outil qui pourrait me le confirmer ?
> >
> >
> >
> > double ode_BAP_impact_2 (const double impact, const cont_impact_struct *const param_int) {
> >
> > BAP_struct_I param_doublet ;
> > memmove (¶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 ; // param_int -> Rabi_0 * exp (-sqr (impact / param_int -> waist)) ;
> >
> > const Thr_level_rho_struct Rho = call_ode_BAP_2 (¶m_doublet, param_int -> tolerance) ;
> >
> > .....
> > Les 3 lignes suivantes n'ont pas d'importance.
> > const double fact_mult = exp (-sqr (impact / param_int -> waist)) ;
> > if (param_int -> type_out == '4') return Rho.rho_01r * fact_mult ;
> > if (param_int -> type_out == '5') return Rho.rho_01i * fact_mult ;
> > }
> >
> > ===========================================================================
> > Patrick DUPRÉ | | email: pdupre@???
> > ===========================================================================
> >
> >
>
>
