Voila je suis entrein de passer Purify sur mon application. Purify
m'indique qu'il y'a des fuites de m=E9moires importante mais pas dans
mon code, voici quelques lignes de Purify :
[I] MPK: Potential memory leak of 1548288 bytes from 18 blocks
allocated in PeekMessageA [USER32.dll]
[W] MLK: Memory leak of 589824 bytes from 28 blocks allocated in
PeekMessageA [USER32.dll]
Memory leak of 113200 bytes from 190 blocks allocated in GetTextFaceA
[GDI32.dll]
Memory leak of 91568 bytes from 173 blocks allocated in
DocumentPropertySheets [WINSPOOL.DRV]
Potential memory leak of 21840 bytes from 8 blocks allocated in
DocumentPropertySheets [WINSPOOL.DRV]
[I] MPK: Potential memory leak of 8720 bytes from 2 blocks allocated in
GetTextFaceA [GDI32.dll]
[W] MLK: Memory leak of 7712 bytes from 12 blocks allocated in
DocumentEvent [WINSPOOL.DRV]
Memory leak of 5312 bytes from 9 blocks allocated in
DocumentPropertySheets [WINSPOOL.DRV]
[I] MPK: Potential memory leak of 3096 bytes from 3 blocks allocated in
PerfClose [WINSPOOL.DRV]
[W] MLK: Memory leak of 1680 bytes from 2 blocks allocated in
SearchPathW [KERNEL32.dll]
[W] MLK: Memory leak of 1680 bytes from 2 blocks allocated in
ClearCustData [OLEAUT32.dll]
Sachant que cette perte de m=E9moire est cumulable avec le nombre
d'excution(des fonctionnalit=E9s sur lesquelles je passe purify).
Questions :
a) Comment faire pour d=E9tourner ces fuites.
b)Est ce qu'on recup=E8re les fuites de m=E9moires une fois qu'on quitte
l'application?. Si la r=E9ponse est oui, alors dans ce cas pourquoi se
prendre la t=EAte =E0 faire des delete sur tous les objets allou=E9s avant
quitter de l'application(biensur qu'on on redemmare la machine on
recupere la m=E9moire l=E0 c'est claire).
b)Est ce qu'on recupère les fuites de mémoires une fois qu'on quitte l'application?
Oui
Si la réponse est oui, alors dans ce cas pourquoi se prendre la tête à faire des delete sur tous les objets alloués avant quitter de l'application.
Certaine application tournent en permanence, dans ce cas la gestion mémoire est importante. Purify detecte aussi les écrasements mémoires, qui sont bien plus problématique. Pour ne pas se prendre la tête avec les fuites mémoires passer sur .NET.
Cordialement, Rémi THOMAS
Bonjour,
b)Est ce qu'on recupère les fuites de mémoires une fois qu'on quitte
l'application?
Oui
Si la réponse est oui, alors dans ce cas pourquoi se
prendre la tête à faire des delete sur tous les objets alloués avant
quitter de l'application.
Certaine application tournent en permanence, dans ce cas la gestion mémoire
est importante.
Purify detecte aussi les écrasements mémoires, qui sont bien plus
problématique.
Pour ne pas se prendre la tête avec les fuites mémoires passer sur .NET.
b)Est ce qu'on recupère les fuites de mémoires une fois qu'on quitte l'application?
Oui
Si la réponse est oui, alors dans ce cas pourquoi se prendre la tête à faire des delete sur tous les objets alloués avant quitter de l'application.
Certaine application tournent en permanence, dans ce cas la gestion mémoire est importante. Purify detecte aussi les écrasements mémoires, qui sont bien plus problématique. Pour ne pas se prendre la tête avec les fuites mémoires passer sur .NET.
Cordialement, Rémi THOMAS
Arnold McDonald \(AMcD\)
Remi THOMAS wrote:
Pour ne pas se prendre la tête avec les fuites mémoires passer sur .NET.
Hé, ça va pas commencer le lobbying, pas toi...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Remi THOMAS wrote:
Pour ne pas se prendre la tête avec les fuites mémoires passer sur
.NET.
Pour ne pas se prendre la tête avec les fuites mémoires passer sur .NET.
Hé, ça va pas commencer le lobbying, pas toi...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Arnold McDonald \(AMcD\)
wrote:
Si la réponse est oui, alors dans ce cas pourquoi se prendre la tête à faire des delete sur tous les objets alloués avant quitter de l'application(biensur qu'on on redemmare la machine on recupere la mémoire là c'est claire).
Eh bien déjà, c'est une question de qualité de programmation. Si t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la différence de Rémi) que TOUT type d'allocation sera automatiquement récupéré à la sortie de ton application. J'en doute même fortemenent :-). Enfin, il y a pleins de cas qui peuvent faire qu'un oubli de désallocation puisse être gênant. Imagine que ton appli alloue 2 Go en mémoire et que ce soit une appli qui se ferme automatiquement 15' après le démarrage (c'est juste un exemple). Suppose qu'un problème survient et qu'elle n'arrive pas à se clôturer, eh bien, le système va pédaler sévèrement...
Autre exemple, suppose que ton appli alloue 2 Go à 12h15 et n'en a plus besoin à 12h18, mais qu'elle ne sera fermée qu'à 18h. Si tu désalloues pas les 2 Go, ils restent alloués pour rien pendant des heures.
Bref, à part cas particulier, ce n'est même pas en fin d'aplli qu'il faut désallouer, mais en fin d'utilisation concrète de l'allocation.
-- Arnold McDonald (AMcD) - Help #29/2006
http://arnold.mcdonald.free.fr/
mohamed92000@hotmail.com wrote:
Si la réponse est oui, alors dans ce cas pourquoi se
prendre la tête à faire des delete sur tous les objets alloués avant
quitter de l'application(biensur qu'on on redemmare la machine on
recupere la mémoire là c'est claire).
Eh bien déjà, c'est une question de qualité de programmation. Si t'alloues,
tu désalloues. Ensuite, je ne suis pas absolument sûr (à la différence de
Rémi) que TOUT type d'allocation sera automatiquement récupéré à la sortie
de ton application. J'en doute même fortemenent :-). Enfin, il y a pleins de
cas qui peuvent faire qu'un oubli de désallocation puisse être gênant.
Imagine que ton appli alloue 2 Go en mémoire et que ce soit une appli qui se
ferme automatiquement 15' après le démarrage (c'est juste un exemple).
Suppose qu'un problème survient et qu'elle n'arrive pas à se clôturer, eh
bien, le système va pédaler sévèrement...
Autre exemple, suppose que ton appli alloue 2 Go à 12h15 et n'en a plus
besoin à 12h18, mais qu'elle ne sera fermée qu'à 18h. Si tu désalloues pas
les 2 Go, ils restent alloués pour rien pendant des heures.
Bref, à part cas particulier, ce n'est même pas en fin d'aplli qu'il faut
désallouer, mais en fin d'utilisation concrète de l'allocation.
Si la réponse est oui, alors dans ce cas pourquoi se prendre la tête à faire des delete sur tous les objets alloués avant quitter de l'application(biensur qu'on on redemmare la machine on recupere la mémoire là c'est claire).
Eh bien déjà, c'est une question de qualité de programmation. Si t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la différence de Rémi) que TOUT type d'allocation sera automatiquement récupéré à la sortie de ton application. J'en doute même fortemenent :-). Enfin, il y a pleins de cas qui peuvent faire qu'un oubli de désallocation puisse être gênant. Imagine que ton appli alloue 2 Go en mémoire et que ce soit une appli qui se ferme automatiquement 15' après le démarrage (c'est juste un exemple). Suppose qu'un problème survient et qu'elle n'arrive pas à se clôturer, eh bien, le système va pédaler sévèrement...
Autre exemple, suppose que ton appli alloue 2 Go à 12h15 et n'en a plus besoin à 12h18, mais qu'elle ne sera fermée qu'à 18h. Si tu désalloues pas les 2 Go, ils restent alloués pour rien pendant des heures.
Bref, à part cas particulier, ce n'est même pas en fin d'aplli qu'il faut désallouer, mais en fin d'utilisation concrète de l'allocation.
-- Arnold McDonald (AMcD) - Help #29/2006
http://arnold.mcdonald.free.fr/
Dominique Vaufreydaz
Bonjour,
Eh bien déjà, c'est une question de qualité de programmation. Si t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la différence de Rémi) que TOUT type d'allocation sera automatiquement récupéré à la sortie de ton application. J'en doute même fortemenent :-). Enfin, il y a pleins de cas qui peuvent faire
Notons que c'est le role de l'OS. C'est pour ca que pour moi Windows 9x et ME ne sont pas des OS. Les NT font ca plutot bien. Par contre, j'ai deja eu des memory leak detectés par purify a la sortie de mon appli et qui n'etait pas de mon fait (memoire alloué avant execution du main de mon prog). Cette applie tournait des millions de fois (je n'exagere pas) et je n'ai jamais eu de probleme. Par contre, pour certain type d'objet systeme, il y a des tempo pour la liberation par le systeme. Juste a titre d'exemple, les sockets "listen" de Windows sont mieux gerer a ce niveau que celle de Linux (je troll pas la, pas la peine d'argumenter des plombes, c'est par l'exemple que j'ai vu ca).
qu'un oubli de désallocation puisse être gênant. Imagine que ton appli alloue 2 Go en mémoire et que ce soit une appli qui se ferme automatiquement 15' après le démarrage (c'est juste un exemple). Suppose qu'un problème survient et qu'elle n'arrive pas à se clôturer, eh bien, le système va pédaler sévèrement... Autre exemple, suppose que ton appli alloue 2 Go à 12h15 et n'en a plus besoin à 12h18, mais qu'elle ne sera fermée qu'à 18h. Si tu désalloues pas les 2 Go, ils restent alloués pour rien pendant des heures. Bref, à part cas particulier, ce n'est même pas en fin d'aplli qu'il faut désallouer, mais en fin d'utilisation concrète de l'allocation.
La c'est meme plus un probleme de l'appli mais de la personne (ou des personnes) qui ont concu l'appli. Notons que maintenant que tout le monde (j'exagere) n'append plus que Java, la notion de gestion de la memoire devitn une notion empirique que tout le monde n'apprend pas de la meme maniere...
Doms.
Bonjour,
Eh bien déjà, c'est une question de qualité de programmation. Si
t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à
la différence de Rémi) que TOUT type d'allocation sera
automatiquement récupéré à la sortie de ton application. J'en doute
même fortemenent :-). Enfin, il y a pleins de cas qui peuvent faire
Notons que c'est le role de l'OS. C'est pour ca que pour moi Windows
9x et ME ne sont pas des OS. Les NT font ca plutot bien.
Par contre, j'ai deja eu des memory leak detectés par purify
a la sortie de mon appli et qui n'etait pas de mon fait (memoire
alloué avant execution du main de mon prog). Cette applie tournait
des millions de fois (je n'exagere pas) et je n'ai jamais eu de probleme.
Par contre, pour certain type d'objet systeme, il y a des tempo
pour la liberation par le systeme. Juste a titre d'exemple, les sockets
"listen" de Windows sont mieux gerer a ce niveau que celle de Linux
(je troll pas la, pas la peine d'argumenter des plombes, c'est par
l'exemple que j'ai vu ca).
qu'un oubli de désallocation puisse être gênant. Imagine que ton
appli alloue 2 Go en mémoire et que ce soit une appli qui se ferme
automatiquement 15' après le démarrage (c'est juste un exemple).
Suppose qu'un problème survient et qu'elle n'arrive pas à se
clôturer, eh bien, le système va pédaler sévèrement... Autre exemple, suppose que ton appli alloue 2 Go à 12h15 et n'en a
plus besoin à 12h18, mais qu'elle ne sera fermée qu'à 18h. Si tu
désalloues pas les 2 Go, ils restent alloués pour rien pendant des
heures. Bref, à part cas particulier, ce n'est même pas en fin d'aplli qu'il
faut désallouer, mais en fin d'utilisation concrète de l'allocation.
La c'est meme plus un probleme de l'appli mais de la personne
(ou des personnes) qui ont concu l'appli. Notons que maintenant
que tout le monde (j'exagere) n'append plus que Java, la notion
de gestion de la memoire devitn une notion empirique que tout
le monde n'apprend pas de la meme maniere...
Eh bien déjà, c'est une question de qualité de programmation. Si t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la différence de Rémi) que TOUT type d'allocation sera automatiquement récupéré à la sortie de ton application. J'en doute même fortemenent :-). Enfin, il y a pleins de cas qui peuvent faire
Notons que c'est le role de l'OS. C'est pour ca que pour moi Windows 9x et ME ne sont pas des OS. Les NT font ca plutot bien. Par contre, j'ai deja eu des memory leak detectés par purify a la sortie de mon appli et qui n'etait pas de mon fait (memoire alloué avant execution du main de mon prog). Cette applie tournait des millions de fois (je n'exagere pas) et je n'ai jamais eu de probleme. Par contre, pour certain type d'objet systeme, il y a des tempo pour la liberation par le systeme. Juste a titre d'exemple, les sockets "listen" de Windows sont mieux gerer a ce niveau que celle de Linux (je troll pas la, pas la peine d'argumenter des plombes, c'est par l'exemple que j'ai vu ca).
qu'un oubli de désallocation puisse être gênant. Imagine que ton appli alloue 2 Go en mémoire et que ce soit une appli qui se ferme automatiquement 15' après le démarrage (c'est juste un exemple). Suppose qu'un problème survient et qu'elle n'arrive pas à se clôturer, eh bien, le système va pédaler sévèrement... Autre exemple, suppose que ton appli alloue 2 Go à 12h15 et n'en a plus besoin à 12h18, mais qu'elle ne sera fermée qu'à 18h. Si tu désalloues pas les 2 Go, ils restent alloués pour rien pendant des heures. Bref, à part cas particulier, ce n'est même pas en fin d'aplli qu'il faut désallouer, mais en fin d'utilisation concrète de l'allocation.
La c'est meme plus un probleme de l'appli mais de la personne (ou des personnes) qui ont concu l'appli. Notons que maintenant que tout le monde (j'exagere) n'append plus que Java, la notion de gestion de la memoire devitn une notion empirique que tout le monde n'apprend pas de la meme maniere...
Doms.
Thierry
"Remi THOMAS" wrote in news:44436cf1$0$31420$:
Pour ne pas se prendre la tête avec les fuites mémoires passer sur .NET.
... ou plutôt apprendre a être rigoureux.
(j'aime pas les garbages collectors).
"Remi THOMAS" <remi@xtware.com> wrote in
news:44436cf1$0$31420$626a54ce@news.free.fr:
Pour ne pas se prendre la tête avec les fuites mémoires passer sur
.NET.
Pour ne pas se prendre la tête avec les fuites mémoires passer sur .NET.
... ou plutôt apprendre a être rigoureux.
(j'aime pas les garbages collectors).
Thierry
"Arnold McDonald (AMcD)" wrote in news:444375b5$0$18251$:
Eh bien déjà, c'est une question de qualité de programmation. Si t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la différence de Rémi) que TOUT type d'allocation sera automatiquement récupéré à la sortie de ton application. J'en doute même fortemenent :-).
Je pense que au moins toute allocation via malloc ou new (qui appelle malloc) est désallouée automatiquement a la fin programme.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les exemples que tu donnes apres).
"Arnold McDonald (AMcD)" <killspammers@free.fr> wrote in
news:444375b5$0$18251$636a55ce@news.free.fr:
Eh bien déjà, c'est une question de qualité de programmation. Si
t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la
différence de Rémi) que TOUT type d'allocation sera automatiquement
récupéré à la sortie de ton application. J'en doute même fortemenent
:-).
Je pense que au moins toute allocation via malloc ou new (qui appelle
malloc) est désallouée automatiquement a la fin programme.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les
exemples que tu donnes apres).
"Arnold McDonald (AMcD)" wrote in news:444375b5$0$18251$:
Eh bien déjà, c'est une question de qualité de programmation. Si t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la différence de Rémi) que TOUT type d'allocation sera automatiquement récupéré à la sortie de ton application. J'en doute même fortemenent :-).
Je pense que au moins toute allocation via malloc ou new (qui appelle malloc) est désallouée automatiquement a la fin programme.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les exemples que tu donnes apres).
Thierry
"Dominique Vaufreydaz" wrote in news::
Notons que c'est le role de l'OS. C'est pour ca que pour moi Windows 9x et ME ne sont pas des OS. Les NT font ca plutot bien. Par contre, j'ai deja eu des memory leak detectés par purify a la sortie de mon appli et qui n'etait pas de mon fait (memoire alloué avant execution du main de mon prog).
T'utilisais les MFC ?
"Dominique Vaufreydaz" <Dominique-Doms.Vaufreydaz@imag.fr> wrote in
news:e22600.20dc.1@invalid.net:
Notons que c'est le role de l'OS. C'est pour ca que pour moi
Windows 9x et ME ne sont pas des OS. Les NT font ca plutot bien.
Par contre, j'ai deja eu des memory leak detectés par purify
a la sortie de mon appli et qui n'etait pas de mon fait (memoire
alloué avant execution du main de mon prog).
Notons que c'est le role de l'OS. C'est pour ca que pour moi Windows 9x et ME ne sont pas des OS. Les NT font ca plutot bien. Par contre, j'ai deja eu des memory leak detectés par purify a la sortie de mon appli et qui n'etait pas de mon fait (memoire alloué avant execution du main de mon prog).
T'utilisais les MFC ?
Arnold McDonald \(AMcD\)
Dominique Vaufreydaz wrote:
Par contre, pour certain type d'objet systeme, il y a des tempo pour la liberation par le systeme. Juste a titre d'exemple, les sockets "listen" de Windows sont mieux gerer a ce niveau que celle de Linux
Oui, très bon exemple. Il y en a pleins d'autres. Je me souviens de certaines expériences sur des objets systèmes et ma surprise en voyant que certains d'entre-eux étaient libérés un peu quand Windows en avait le temps...
Notons que maintenant que tout le monde (j'exagere) n'append plus que Java, la notion de gestion de la memoire devitn une notion empirique que tout le monde n'apprend pas de la meme maniere...
Oh, ça change pas. Un branleur, c'est un branleur, quel que soit le langage, l'OS ou l'époque. Combien de fois ai-je entendu de codeurs Windows C sortir "pourquoi s'ennuyer avec les désallocations, pourquoi gérer à l'octet près ta liste de 15.000 éléments, t'as 1 Go de RAM mon pote !". C'est sûr qu'aujourd'hui, entre les clickodromes et les langages a garbage collector, c'est pas les occasions qui manquent pour produire des codeurs moyens ou, tout au moins, qui ne se poseront pas beaucoup de questions :-(.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Dominique Vaufreydaz wrote:
Par contre, pour certain type d'objet systeme, il y a
des tempo pour la liberation par le systeme. Juste a titre
d'exemple, les sockets "listen" de Windows sont mieux gerer a ce
niveau que celle de Linux
Oui, très bon exemple. Il y en a pleins d'autres. Je me souviens de
certaines expériences sur des objets systèmes et ma surprise en voyant que
certains d'entre-eux étaient libérés un peu quand Windows en avait le
temps...
Notons que maintenant
que tout le monde (j'exagere) n'append plus que Java, la notion
de gestion de la memoire devitn une notion empirique que tout
le monde n'apprend pas de la meme maniere...
Oh, ça change pas. Un branleur, c'est un branleur, quel que soit le langage,
l'OS ou l'époque. Combien de fois ai-je entendu de codeurs Windows C sortir
"pourquoi s'ennuyer avec les désallocations, pourquoi gérer à l'octet près
ta liste de 15.000 éléments, t'as 1 Go de RAM mon pote !". C'est sûr
qu'aujourd'hui, entre les clickodromes et les langages a garbage collector,
c'est pas les occasions qui manquent pour produire des codeurs moyens ou,
tout au moins, qui ne se poseront pas beaucoup de questions :-(.
Par contre, pour certain type d'objet systeme, il y a des tempo pour la liberation par le systeme. Juste a titre d'exemple, les sockets "listen" de Windows sont mieux gerer a ce niveau que celle de Linux
Oui, très bon exemple. Il y en a pleins d'autres. Je me souviens de certaines expériences sur des objets systèmes et ma surprise en voyant que certains d'entre-eux étaient libérés un peu quand Windows en avait le temps...
Notons que maintenant que tout le monde (j'exagere) n'append plus que Java, la notion de gestion de la memoire devitn une notion empirique que tout le monde n'apprend pas de la meme maniere...
Oh, ça change pas. Un branleur, c'est un branleur, quel que soit le langage, l'OS ou l'époque. Combien de fois ai-je entendu de codeurs Windows C sortir "pourquoi s'ennuyer avec les désallocations, pourquoi gérer à l'octet près ta liste de 15.000 éléments, t'as 1 Go de RAM mon pote !". C'est sûr qu'aujourd'hui, entre les clickodromes et les langages a garbage collector, c'est pas les occasions qui manquent pour produire des codeurs moyens ou, tout au moins, qui ne se poseront pas beaucoup de questions :-(.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Vincent Burel
"Thierry" wrote in message news:
"Arnold McDonald (AMcD)" wrote in news:444375b5$0$18251$:
> Eh bien déjà, c'est une question de qualité de programmation. Si > t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la > différence de Rémi) que TOUT type d'allocation sera automatiquement > récupéré à la sortie de ton application. J'en doute même fortemenent > :-).
Je pense que au moins toute allocation via malloc ou new (qui appelle malloc) est désallouée automatiquement a la fin programme.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les exemples que tu donnes apres).
Oui, et surtout dans les composants dynamiques (DLL, COM etc), charger , décharger des composants qui fuient, c'est la garantie d'obtenir un plantage, parfois après des heures de travail... où l'on commencait à croire que tel ou tel logiciels était stable et fiable...
VB
"Thierry" <thierry@yarglah.invalid> wrote in message
news:Xns97A963A1AE78Apouletetcetcetc@213.41.185.117...
"Arnold McDonald (AMcD)" <killspammers@free.fr> wrote in
news:444375b5$0$18251$636a55ce@news.free.fr:
> Eh bien déjà, c'est une question de qualité de programmation. Si
> t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la
> différence de Rémi) que TOUT type d'allocation sera automatiquement
> récupéré à la sortie de ton application. J'en doute même fortemenent
> :-).
Je pense que au moins toute allocation via malloc ou new (qui appelle
malloc) est désallouée automatiquement a la fin programme.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les
exemples que tu donnes apres).
Oui, et surtout dans les composants dynamiques (DLL, COM etc), charger ,
décharger des composants qui fuient, c'est la garantie d'obtenir un
plantage, parfois après des heures de travail... où l'on commencait à croire
que tel ou tel logiciels était stable et fiable...
"Arnold McDonald (AMcD)" wrote in news:444375b5$0$18251$:
> Eh bien déjà, c'est une question de qualité de programmation. Si > t'alloues, tu désalloues. Ensuite, je ne suis pas absolument sûr (à la > différence de Rémi) que TOUT type d'allocation sera automatiquement > récupéré à la sortie de ton application. J'en doute même fortemenent > :-).
Je pense que au moins toute allocation via malloc ou new (qui appelle malloc) est désallouée automatiquement a la fin programme.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les exemples que tu donnes apres).
Oui, et surtout dans les composants dynamiques (DLL, COM etc), charger , décharger des composants qui fuient, c'est la garantie d'obtenir un plantage, parfois après des heures de travail... où l'on commencait à croire que tel ou tel logiciels était stable et fiable...
VB
Aurelien Regat-Barrel
Thierry a écrit :
Je pense que au moins toute allocation via malloc ou new (qui appelle malloc) est désallouée automatiquement a la fin programme.
Et même en général c'est pas Windows qui le fait mais la lib standard du compilo. Pareil pour la fermeture des fichiers. Le problème des fuites c'est la surconsommation mémoire, qui en général est couplée avec une non gestion des erreurs d'allocation mémoire, et tout ça se traduit pas des crashs aléatoires, d'autant plus rares et difficilement reproductibles qu'il y a de la mémoire dispo.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les exemples que tu donnes apres).
Sur le forum C++, l'exemple du fichier temporaire non supprimé a été donné. C'est bien de la mémoire gaspillée, et l'OS n'y peut pas grand chose. Y'a qu'à regarder le contenu de %tmp% :/
-- Aurélien Regat-Barrel
Thierry a écrit :
Je pense que au moins toute allocation via malloc ou new (qui appelle
malloc) est désallouée automatiquement a la fin programme.
Et même en général c'est pas Windows qui le fait mais la lib standard du
compilo. Pareil pour la fermeture des fichiers.
Le problème des fuites c'est la surconsommation mémoire, qui en général
est couplée avec une non gestion des erreurs d'allocation mémoire, et
tout ça se traduit pas des crashs aléatoires, d'autant plus rares et
difficilement reproductibles qu'il y a de la mémoire dispo.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les
exemples que tu donnes apres).
Sur le forum C++, l'exemple du fichier temporaire non supprimé a été
donné. C'est bien de la mémoire gaspillée, et l'OS n'y peut pas grand
chose. Y'a qu'à regarder le contenu de %tmp% :/
Je pense que au moins toute allocation via malloc ou new (qui appelle malloc) est désallouée automatiquement a la fin programme.
Et même en général c'est pas Windows qui le fait mais la lib standard du compilo. Pareil pour la fermeture des fichiers. Le problème des fuites c'est la surconsommation mémoire, qui en général est couplée avec une non gestion des erreurs d'allocation mémoire, et tout ça se traduit pas des crashs aléatoires, d'autant plus rares et difficilement reproductibles qu'il y a de la mémoire dispo.
Mais c'est pas une excuse pour ne pas faire gaffe aux desallocs (cf les exemples que tu donnes apres).
Sur le forum C++, l'exemple du fichier temporaire non supprimé a été donné. C'est bien de la mémoire gaspillée, et l'OS n'y peut pas grand chose. Y'a qu'à regarder le contenu de %tmp% :/
