toujours à la recherche de fuites mémoires sur des applis en tâche de fond
réalisées avec WD75, je viens de m'apercevoir qu'avec la 205s, flistefichier
pose des soucis.
Il me semble pourtant avoir testé avec des versions précédentes cette
fonction sans avoir eu une consomation significative de mémoire au bout de
24h.
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce petit
projet test pendant au moins 24 heures, avec la 205s et avec d'autres
versions avant que je signale tout ceci au ST ?
A télécharger et à laisser tourner pendant 24 heures (avec un EXE généré).
Pour ceux qui ne veulent pas participer, voici pour info le code utilisé :
93 Mo de mémoire utilisée au bout de 15 heures !!
**** Déclaration globales Fenetre
gf_bSortir est un booléen
**** clic sur bouton 1 (avec libellé "GO")
SI MoiMême..Libellé ~= "GO" ALORS
MoiMême..Libellé = "STOP"
gf_bSortir = Faux
proc_boucle()
SINON
MoiMême..Libellé = "GO"
gf_bSortir = Vrai
FIN
**** procédure locale proc_boucle
PROCEDURE proc_boucle()
n est un entier
BOUCLE
n = fListeFichier("c:\*.*", "proc_vide")
// ne pas conserver la trace, cela fausse la conso mémoire
// Trace(n +" fichiers listés")
Multitache(-1)
SI gf_bSortir ALORS SORTIR
FIN
**** procédure locale proc_vide
PROCEDURE proc_vide(sChemin, sFichier, eChange, ePointeur)
SI eChange = flChangeRépertoire ALORS RENVOYER Faux
Merci, A+
--
Romain PETIT
(mailto:rompetit_chez_ifrance.com)
si ton projet réalise seul ses rapports de consomation je peux activer tes tests sur 2 machines W2k sur 24/48h
passe moi le tout en direct.
@+ R&B
Romain PETIT wrote:
Bonjour,
toujours à la recherche de fuites mémoires sur des applis en tâche de fond réalisées avec WD75, je viens de m'apercevoir qu'avec la 205s, flistefichier pose des soucis.
Il me semble pourtant avoir testé avec des versions précédentes cette fonction sans avoir eu une consomation significative de mémoire au bout de 24h.
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce petit projet test pendant au moins 24 heures, avec la 205s et avec d'autres versions avant que je signale tout ceci au ST ?
A télécharger et à laisser tourner pendant 24 heures (avec un EXE généré).
Pour ceux qui ne veulent pas participer, voici pour info le code utilisé : 93 Mo de mémoire utilisée au bout de 15 heures !!
**** Déclaration globales Fenetre gf_bSortir est un booléen
**** clic sur bouton 1 (avec libellé "GO") SI MoiMême..Libellé ~= "GO" ALORS MoiMême..Libellé = "STOP" gf_bSortir = Faux proc_boucle() SINON MoiMême..Libellé = "GO" gf_bSortir = Vrai FIN
**** procédure locale proc_boucle PROCEDURE proc_boucle() n est un entier BOUCLE n = fListeFichier("c:*.*", "proc_vide") // ne pas conserver la trace, cela fausse la conso mémoire // Trace(n +" fichiers listés") Multitache(-1) SI gf_bSortir ALORS SORTIR FIN
**** procédure locale proc_vide PROCEDURE proc_vide(sChemin, sFichier, eChange, ePointeur) SI eChange = flChangeRépertoire ALORS RENVOYER Faux
Merci, A+
Salut Romain
si ton projet réalise seul ses rapports de consomation je peux activer
tes tests sur 2 machines W2k sur 24/48h
passe moi le tout en direct.
@+ R&B
Romain PETIT wrote:
Bonjour,
toujours à la recherche de fuites mémoires sur des applis en tâche de fond
réalisées avec WD75, je viens de m'apercevoir qu'avec la 205s, flistefichier
pose des soucis.
Il me semble pourtant avoir testé avec des versions précédentes cette
fonction sans avoir eu une consomation significative de mémoire au bout de
24h.
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce petit
projet test pendant au moins 24 heures, avec la 205s et avec d'autres
versions avant que je signale tout ceci au ST ?
A télécharger et à laisser tourner pendant 24 heures (avec un EXE généré).
Pour ceux qui ne veulent pas participer, voici pour info le code utilisé :
93 Mo de mémoire utilisée au bout de 15 heures !!
**** Déclaration globales Fenetre
gf_bSortir est un booléen
**** clic sur bouton 1 (avec libellé "GO")
SI MoiMême..Libellé ~= "GO" ALORS
MoiMême..Libellé = "STOP"
gf_bSortir = Faux
proc_boucle()
SINON
MoiMême..Libellé = "GO"
gf_bSortir = Vrai
FIN
**** procédure locale proc_boucle
PROCEDURE proc_boucle()
n est un entier
BOUCLE
n = fListeFichier("c:*.*", "proc_vide")
// ne pas conserver la trace, cela fausse la conso mémoire
// Trace(n +" fichiers listés")
Multitache(-1)
SI gf_bSortir ALORS SORTIR
FIN
**** procédure locale proc_vide
PROCEDURE proc_vide(sChemin, sFichier, eChange, ePointeur)
SI eChange = flChangeRépertoire ALORS RENVOYER Faux
si ton projet réalise seul ses rapports de consomation je peux activer tes tests sur 2 machines W2k sur 24/48h
passe moi le tout en direct.
@+ R&B
Romain PETIT wrote:
Bonjour,
toujours à la recherche de fuites mémoires sur des applis en tâche de fond réalisées avec WD75, je viens de m'apercevoir qu'avec la 205s, flistefichier pose des soucis.
Il me semble pourtant avoir testé avec des versions précédentes cette fonction sans avoir eu une consomation significative de mémoire au bout de 24h.
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce petit projet test pendant au moins 24 heures, avec la 205s et avec d'autres versions avant que je signale tout ceci au ST ?
A télécharger et à laisser tourner pendant 24 heures (avec un EXE généré).
Pour ceux qui ne veulent pas participer, voici pour info le code utilisé : 93 Mo de mémoire utilisée au bout de 15 heures !!
**** Déclaration globales Fenetre gf_bSortir est un booléen
**** clic sur bouton 1 (avec libellé "GO") SI MoiMême..Libellé ~= "GO" ALORS MoiMême..Libellé = "STOP" gf_bSortir = Faux proc_boucle() SINON MoiMême..Libellé = "GO" gf_bSortir = Vrai FIN
**** procédure locale proc_boucle PROCEDURE proc_boucle() n est un entier BOUCLE n = fListeFichier("c:*.*", "proc_vide") // ne pas conserver la trace, cela fausse la conso mémoire // Trace(n +" fichiers listés") Multitache(-1) SI gf_bSortir ALORS SORTIR FIN
**** procédure locale proc_vide PROCEDURE proc_vide(sChemin, sFichier, eChange, ePointeur) SI eChange = flChangeRépertoire ALORS RENVOYER Faux
Merci, A+
Romain PETIT
R&B a écrit :
si ton projet réalise seul ses rapports de consomation
Euh, non malheureusement (gestionnaire des tâches).
je peux activer tes tests sur 2 machines W2k sur 24/48h
Si 1 petite fenêtre sur tes machines ne te pose pas de problème pour 24h et si tu peux noter l'utilisation de la mémoire, je veux bien.
passe moi le tout en direct.
Ok,
A+
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
R&B a écrit :
si ton projet réalise seul ses rapports de consomation
Euh, non malheureusement (gestionnaire des tâches).
je peux activer
tes tests sur 2 machines W2k sur 24/48h
Si 1 petite fenêtre sur tes machines ne te pose pas de problème pour 24h et
si tu peux noter l'utilisation de la mémoire, je veux bien.
passe moi le tout en direct.
Ok,
A+
--
Romain PETIT
(mailto:rompetit_chez_ifrance.com)
On Tue, 9 Sep 2003 10:26:16 +0200, Benjamin Cabé wrote:
je viens de télécharger ton soft je vais faire un test sur 24h ou plus
bonne journée, benjamin
oups, 500 ko au bout de 5 minutes.. pas bon ça... snif snif
Pascal H
"Romain PETIT" a écrit dans news:3f5d8466$0$20652$:
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce petit projet test pendant au moins 24 heures, avec la 205s et avec d'autres versions avant que je signale tout ceci au ST ?
Salut Romain et les autres. Je lance ça sur ma machine, NT4 SP6a + WD 7.5 203m (!) Je colle un monitoring sur le processus et je te donne le résultat (bilan intermédiaire ce soir puis définitif jeudi matin)
-- Ne pas pouvoir revenir en arrière est une forme de progression. [ Frédéric Dard ]
Pascal
"Romain PETIT" <rompetit@invalidifrance.com> a écrit dans
news:3f5d8466$0$20652$626a54ce@news.free.fr:
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner
ce petit projet test pendant au moins 24 heures, avec la 205s et
avec d'autres versions avant que je signale tout ceci au ST ?
Salut Romain et les autres.
Je lance ça sur ma machine, NT4 SP6a + WD 7.5 203m (!)
Je colle un monitoring sur le processus et je te donne le résultat
(bilan intermédiaire ce soir puis définitif jeudi matin)
--
Ne pas pouvoir revenir en arrière est une forme de progression.
[ Frédéric Dard ]
"Romain PETIT" a écrit dans news:3f5d8466$0$20652$:
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce petit projet test pendant au moins 24 heures, avec la 205s et avec d'autres versions avant que je signale tout ceci au ST ?
Salut Romain et les autres. Je lance ça sur ma machine, NT4 SP6a + WD 7.5 203m (!) Je colle un monitoring sur le processus et je te donne le résultat (bilan intermédiaire ce soir puis définitif jeudi matin)
-- Ne pas pouvoir revenir en arrière est une forme de progression. [ Frédéric Dard ]
Pascal
T. Pruvot
Il faudrait peut etre aussi tester le mode fRep(C:*.*,frFichier) fRep("",frFichier)
"Romain PETIT" a écrit dans le message news: 3f5d8466$0$20652$
Bonjour,
toujours à la recherche de fuites mémoires sur des applis en tâche de fond réalisées avec WD75, je viens de m'apercevoir qu'avec la 205s,
flistefichier
pose des soucis.
Il me semble pourtant avoir testé avec des versions précédentes cette fonction sans avoir eu une consomation significative de mémoire au bout de 24h.
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce
petit
projet test pendant au moins 24 heures, avec la 205s et avec d'autres versions avant que je signale tout ceci au ST ?
A télécharger et à laisser tourner pendant 24 heures (avec un EXE généré).
Pour ceux qui ne veulent pas participer, voici pour info le code utilisé : 93 Mo de mémoire utilisée au bout de 15 heures !!
**** Déclaration globales Fenetre gf_bSortir est un booléen
**** clic sur bouton 1 (avec libellé "GO") SI MoiMême..Libellé ~= "GO" ALORS MoiMême..Libellé = "STOP" gf_bSortir = Faux proc_boucle() SINON MoiMême..Libellé = "GO" gf_bSortir = Vrai FIN
**** procédure locale proc_boucle PROCEDURE proc_boucle() n est un entier BOUCLE n = fListeFichier("c:*.*", "proc_vide") // ne pas conserver la trace, cela fausse la conso mémoire // Trace(n +" fichiers listés") Multitache(-1) SI gf_bSortir ALORS SORTIR FIN
**** procédure locale proc_vide PROCEDURE proc_vide(sChemin, sFichier, eChange, ePointeur) SI eChange = flChangeRépertoire ALORS RENVOYER Faux
Merci, A+
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
Il faudrait peut etre aussi tester le mode
fRep(C:*.*,frFichier)
fRep("",frFichier)
"Romain PETIT" <rompetit@invalidifrance.com> a écrit dans le message news:
3f5d8466$0$20652$626a54ce@news.free.fr...
Bonjour,
toujours à la recherche de fuites mémoires sur des applis en tâche de fond
réalisées avec WD75, je viens de m'apercevoir qu'avec la 205s,
flistefichier
pose des soucis.
Il me semble pourtant avoir testé avec des versions précédentes cette
fonction sans avoir eu une consomation significative de mémoire au bout de
24h.
Pouvez-vous confirmer ou infirmer mes soupcons en laissant tourner ce
petit
projet test pendant au moins 24 heures, avec la 205s et avec d'autres
versions avant que je signale tout ceci au ST ?
A télécharger et à laisser tourner pendant 24 heures (avec un EXE généré).
Pour ceux qui ne veulent pas participer, voici pour info le code utilisé :
93 Mo de mémoire utilisée au bout de 15 heures !!
**** Déclaration globales Fenetre
gf_bSortir est un booléen
**** clic sur bouton 1 (avec libellé "GO")
SI MoiMême..Libellé ~= "GO" ALORS
MoiMême..Libellé = "STOP"
gf_bSortir = Faux
proc_boucle()
SINON
MoiMême..Libellé = "GO"
gf_bSortir = Vrai
FIN
**** procédure locale proc_boucle
PROCEDURE proc_boucle()
n est un entier
BOUCLE
n = fListeFichier("c:*.*", "proc_vide")
// ne pas conserver la trace, cela fausse la conso mémoire
// Trace(n +" fichiers listés")
Multitache(-1)
SI gf_bSortir ALORS SORTIR
FIN
**** procédure locale proc_vide
PROCEDURE proc_vide(sChemin, sFichier, eChange, ePointeur)
SI eChange = flChangeRépertoire ALORS RENVOYER Faux
Merci, A+
--
Romain PETIT
(mailto:rompetit_chez_ifrance.com)
Pour ceux qui ne veulent pas participer, voici pour info le code utilisé : 93 Mo de mémoire utilisée au bout de 15 heures !!
**** Déclaration globales Fenetre gf_bSortir est un booléen
**** clic sur bouton 1 (avec libellé "GO") SI MoiMême..Libellé ~= "GO" ALORS MoiMême..Libellé = "STOP" gf_bSortir = Faux proc_boucle() SINON MoiMême..Libellé = "GO" gf_bSortir = Vrai FIN
**** procédure locale proc_boucle PROCEDURE proc_boucle() n est un entier BOUCLE n = fListeFichier("c:*.*", "proc_vide") // ne pas conserver la trace, cela fausse la conso mémoire // Trace(n +" fichiers listés") Multitache(-1) SI gf_bSortir ALORS SORTIR FIN
**** procédure locale proc_vide PROCEDURE proc_vide(sChemin, sFichier, eChange, ePointeur) SI eChange = flChangeRépertoire ALORS RENVOYER Faux
Merci, A+
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
Romain PETIT
T. Pruvot a écrit :
Il faudrait peut etre aussi tester le mode fRep(C:*.*,frFichier) fRep("",frFichier)
Salut,
J'y avais pensé mais fRep pourra difficilement me servir de contournement à cause de ça : "Dans une boucle de parcours de répertoires effectuée avec fRep, il ne faut pas utiliser la fonction fCopieFichier."
A+ -- Romain PETIT (mailto:rompetit_chez_ifrance.com)
T. Pruvot a écrit :
Il faudrait peut etre aussi tester le mode
fRep(C:*.*,frFichier)
fRep("",frFichier)
Salut,
J'y avais pensé mais fRep pourra difficilement me servir de contournement à
cause de ça :
"Dans une boucle de parcours de répertoires effectuée avec fRep, il ne faut
pas utiliser la fonction fCopieFichier."
A+
--
Romain PETIT
(mailto:rompetit_chez_ifrance.com)
Il faudrait peut etre aussi tester le mode fRep(C:*.*,frFichier) fRep("",frFichier)
Salut,
J'y avais pensé mais fRep pourra difficilement me servir de contournement à cause de ça : "Dans une boucle de parcours de répertoires effectuée avec fRep, il ne faut pas utiliser la fonction fCopieFichier."
A+ -- Romain PETIT (mailto:rompetit_chez_ifrance.com)
Benjamin Cabé
bon bon... L'appli démarre avec une utilisation de 4 Mo, puis au bout d'un peu plus d'une heure on en est déjà à 13 Mo ! Donc voilà, j'arrête là de mon côté, j'ai besoin de rebooter ! Je suis sous W2K SP4, WD7.5 204g Il y a donc bien une fuite dans fListeFichier(), visiblement
a+ benj
bon bon...
L'appli démarre avec une utilisation de 4 Mo, puis au bout d'un peu plus
d'une heure on en est déjà à 13 Mo !
Donc voilà, j'arrête là de mon côté, j'ai besoin de rebooter !
Je suis sous W2K SP4, WD7.5 204g
Il y a donc bien une fuite dans fListeFichier(), visiblement
bon bon... L'appli démarre avec une utilisation de 4 Mo, puis au bout d'un peu plus d'une heure on en est déjà à 13 Mo ! Donc voilà, j'arrête là de mon côté, j'ai besoin de rebooter ! Je suis sous W2K SP4, WD7.5 204g Il y a donc bien une fuite dans fListeFichier(), visiblement
a+ benj
Pascal H
Benjamin Cabé a écrit dans news::
bon bon... L'appli démarre avec une utilisation de 4 Mo, puis au bout d'un peu plus d'une heure on en est déjà à 13 Mo ! Donc voilà, j'arrête là de mon côté, j'ai besoin de rebooter ! Je suis sous W2K SP4, WD7.5 204g Il y a donc bien une fuite dans fListeFichier(), visiblement
a+ benj
Pas loin de 10 Mo pour moi aussi. Et j'ai besoin des ressources de ma machine, donc je coupe pour le moment. Ce qui est assez effarant c'est que le clic sur le bouton arrêter ne diminue en rien l'utilisation mémoire :( Il faut croire que les appels successifs aux fonctions système faits par WD engendrent cet accroissement. Pas d'augmentation de handle par contre.
Rappel: OS NT4 WKS + Windev 203m (donc le problème n'est pas récent)
--
Pascal
Benjamin Cabé <none@cabe.com> a écrit dans
news:1by0n4hr015n6.ldqtxqs0bsr0.dlg@40tude.net:
bon bon...
L'appli démarre avec une utilisation de 4 Mo, puis au bout d'un
peu plus d'une heure on en est déjà à 13 Mo !
Donc voilà, j'arrête là de mon côté, j'ai besoin de rebooter !
Je suis sous W2K SP4, WD7.5 204g
Il y a donc bien une fuite dans fListeFichier(), visiblement
a+
benj
Pas loin de 10 Mo pour moi aussi.
Et j'ai besoin des ressources de ma machine, donc je coupe pour le
moment.
Ce qui est assez effarant c'est que le clic sur le bouton arrêter ne
diminue en rien l'utilisation mémoire :(
Il faut croire que les appels successifs aux fonctions système faits
par WD engendrent cet accroissement. Pas d'augmentation de handle par
contre.
Rappel: OS NT4 WKS + Windev 203m (donc le problème n'est pas récent)
bon bon... L'appli démarre avec une utilisation de 4 Mo, puis au bout d'un peu plus d'une heure on en est déjà à 13 Mo ! Donc voilà, j'arrête là de mon côté, j'ai besoin de rebooter ! Je suis sous W2K SP4, WD7.5 204g Il y a donc bien une fuite dans fListeFichier(), visiblement
a+ benj
Pas loin de 10 Mo pour moi aussi. Et j'ai besoin des ressources de ma machine, donc je coupe pour le moment. Ce qui est assez effarant c'est que le clic sur le bouton arrêter ne diminue en rien l'utilisation mémoire :( Il faut croire que les appels successifs aux fonctions système faits par WD engendrent cet accroissement. Pas d'augmentation de handle par contre.
Rappel: OS NT4 WKS + Windev 203m (donc le problème n'est pas récent)
--
Pascal
Romain PETIT
Pascal H a écrit :
Il y a donc bien une fuite dans fListeFichier(), visiblement
Pas loin de 10 Mo pour moi aussi. Et j'ai besoin des ressources de ma machine, donc je coupe pour le moment.
Bon, je crois que même avec 1 ou 2 heures, le test est concluant. J'envoie la description du problème au ST et j'enregistre le dysfonctionnement sur windevasso.
Merci de votre participation (malgré eux) à "la politique d'amélioration constante des produits PC SOFT".
A+
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
Pascal H a écrit :
Il y a donc bien une fuite dans fListeFichier(), visiblement
Pas loin de 10 Mo pour moi aussi.
Et j'ai besoin des ressources de ma machine, donc je coupe pour le
moment.
Bon, je crois que même avec 1 ou 2 heures, le test est concluant.
J'envoie la description du problème au ST et j'enregistre le
dysfonctionnement sur windevasso.
Merci de votre participation (malgré eux) à "la politique d'amélioration
constante des produits PC SOFT".
A+
--
Romain PETIT
(mailto:rompetit_chez_ifrance.com)
Il y a donc bien une fuite dans fListeFichier(), visiblement
Pas loin de 10 Mo pour moi aussi. Et j'ai besoin des ressources de ma machine, donc je coupe pour le moment.
Bon, je crois que même avec 1 ou 2 heures, le test est concluant. J'envoie la description du problème au ST et j'enregistre le dysfonctionnement sur windevasso.
Merci de votre participation (malgré eux) à "la politique d'amélioration constante des produits PC SOFT".
A+
-- Romain PETIT (mailto:rompetit_chez_ifrance.com)
