Discussion :

[Higgins]

Bonjour,

Je constate dans mon application que la commande "free" ne libère pas forcément la mémoire associée à un objet.
voici un exemple de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
var monObjet:TSQLStoredProc;
begin
   monObjet:=TSQLStroredProc.create(nil);
  with monObjet do
  begin
        SQLConnection:=maConnexion;       
        storedprocname:=maprocedure;
       open;
       //ici traitement des données lues
  end;
monObjet.close;
monObjet.free;
end;

Après l'appel "monObjet.free", la variable ne passe pas à nil. Sa propriété componentState passe à csDestroying mais l'objet reste en mémoire, comme s'il attendait un garbageCollector.
Résultat, lorsque la procédure est appelée en boucle, la mémoire sature et je finis par avoir l'erreur "mémoire insuffisante"
Existe-t-il un moyen de forcer la destruction de cet objet?

[retwas]

FreeAndNil ?

[Higgins]

Déjà essayé, pas mieux

[e-ric]

As-tu consulté les sources de ta classe ?

Tu compiles bien en 32 bits ?

[Higgins]

As-tu consulté les sources de ta classe ?

Tu compiles bien en 32 bits ?

Oui, c'est moi qui les écris les classes
En général, je n'ai pas de problème, mais là, la classe en question c'est TSQLStoredProc (foruni par DBX)

J'ai fait un test rapide en remplaçant le TSQLStoredProc par un TSQLQuery, l'empreinte mémoire augmente moins vite

[e-ric]

(je parle dans le cadre de Delphi 7)

Es-tu sûr d'atteindre le Free pour commencer ? est-ce que l'ajout d'un bloc protégé n'améliorerait pas la situation ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
monObjet:=TSQLStroredProc.create(nil);
try
  with monObjet do
  begin
    SQLConnection:=maConnexion;       
    storedprocname:=maprocedure;
    open;
    //ici traitement des données lues
  end;
  monObjet.close;
finally
  monObjet.free;
end;

Pour approfondir, active les DCU de débogage et trace l'exécution dans les sources de la VCL (je sais, c'est fastidieux). L'unité est SqlExpr pour les composants DBExpress.

Autre piste: tu parles de boucle dans ton premier post, peux-tu déplacer la boucle dans la partie traitement des données lues ? de manière à n'ouvrir qu'une seule fois la procédure stockée.

@+

[ShaiLeTroll]

On peut alléger la syntaxe à l'extrême

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
  with TSQLStroredProc.create(nil) do
  try
    SQLConnection:=maConnexion;       
    storedprocname:=maprocedure;
    open;
    //ici traitement des données lues
    close;
  finally
    free;
  end;

Pour le phénomène GarbageCollector, je t'invite a fouillé sur le forum au sujet du gestionnaire de mémoire de Delphi 2007 basé sur FastMM
Et sa gestion de la mémoire via allocation de bloc

Est-ce que tu ne lance QUE le code que tu as fourni pour ton test mémoire ?
Si oui, effectivement, le TSQLStroredProc serait en cause
Si non, ton traite fausse le test de fuite évidemment

Ce n'est peut-être pas ton TSQLStroredProc qui fuit mais un autre objet alloué dans le même bloc
Comme tu appelles surement tout le temps le code par le même chemin, tu as toujours cet autre objet
À un final, comme tu as un autre qui fuit, c'est tout le bloc qui est bloqué

Sinon, il n'y a pas forcément de mise à zéro du contenu dans objet, les pointeurs sont mis à nil via FreeAndNil même si je le fais, Est-ce bien utile ? par exemple un double appel de destroy fait mal en fin d'application (si un invalid pointer ... n'arrive pas avant)
ne pas oublier que le Destroy utilisé pour nettoyer une exception dans le Create

Parfois l'erreur "mémoire insuffisante" est fausse, c'est plutôt un problème de handle disponible ou qu'il n'arrive pas à allouer dans un bloc la mémoire demandée, j'ignore comment fonctionne une variable allouée dans plusieurs bloc (Est-ce possible ?)

Par contre, les entiers comme componentState reste en mémoire, en fait, si tu conserve le pointeur, la zone de mémoire tant qu'elle n'est pas réutilise contient les valeurs de l'objet
C'est un autre traitement qui aura peut-être un emplacement qui chevauche celui laissé libre par TSQLStoredProc qui modifiera le contenu, un autre objet commencera par tout mettre à zéro, un record déclaré en variable locale lui contiendra les valeurs et faudra pas oublier de bien remplir ce record !

En C++Builder 2007 et XE2, j'ai utilise massivement du TSQLQuery, instancié et libéré à la volée dans des programmes batch tournant 24/24 pendant plusieurs mois sans être éteind, je n'ai pas vu de fuite mémoire dans ces composants, le volume de donnée était très faible, un Open ne renvoyait souvent qu'une ligne précise
les requetes renvoyant genre 1000 ou 10000 était lancé au démarrage de programme ou lors d'une opération de synchronisation (10 à 100 fois par jour, rien par rapport au 10 000 à 100 000 event jour inséré dans l'historique)

le ficher DB de Sybase Anywhere ne faisait que 5Mo pour la DB de config et par fois entre 100Mo et 1Go sur l'historique des 3 derniers mois mais ce dernier n'était que alimenté par les batch, sa consultation n'étant que dans les modules de stat et reporting qui eux consommait allégrement (pire sous Crystal 12 en .NET)
je n'utilisais pas le TSQLStoredProc

[Higgins]

Est-ce que tu ne lance QUE le code que tu as fourni pour ton test mémoire ?
Si oui, effectivement, le TSQLStroredProc serait en cause
Si non, ton traite fausse le test de fuite évidemment
Ce n'est peut-être pas ton TSQLStroredProc qui fuit mais un autre objet alloué dans le même bloc
Comme tu appelles surement tout le temps le code par le même chemin, tu as toujours cet autre objet
À un final, comme tu as un autre qui fuit, c'est tout le bloc qui est bloqué

En réalité, j'exécute du code avant et après, mais lorsque je place ce bloc en commentaires, il n'y a plus de fuite.
Pour répondre à e-ric, oui je suis sûr d'atteindre le free, j'y ai placé un point d'arrêt pour contrôler.

Parfois l'erreur "mémoire insuffisante" est fausse, c'est plutôt un problème de handle disponible ou qu'il n'arrive pas à allouer dans un bloc la mémoire demandée, j'ignore comment fonctionne une variable allouée dans plusieurs bloc (Est-ce possible ?)

Effectivement, ce message d'erreur apparait ne exécution "standard". En mode debug, l'erreur exacte est "DBX: Erreur fournisseur". Mais je n'ai trouvé aucune aide ou piste avec cette erreur et comme je vois augmenter l'empreinte mémoire au fur et à mesure de l'exécution, je me suis concentré sur la fuite de mémoire.

Par contre, les entiers comme componentState reste en mémoire, en fait, si tu conserve le pointeur, la zone de mémoire tant qu'elle n'est pas réutilise contient les valeurs de l'objet

C'est bon à savoir

C'est un autre traitement qui aura peut-être un emplacement qui chevauche celui laissé libre par TSQLStoredProc qui modifiera le contenu, un autre objet commencera par tout mettre à zéro, un record déclaré en variable locale lui contiendra les valeurs et faudra pas oublier de bien remplir ce record !

C'est justement parce que j'avais envisagé cette hypothèse que je cherche un moyen de "vider" la mémoire occupée par le TSQLProc après son exécution.

je n'utilisais pas le TSQLStoredProc

Moi non plus. Dans ce cas précis, c'est pour faciliter le portage sur d'autres SGBDR, mais effectivement, j'observe une nette amélioration en remplaçant le TSQLStoredProc par un tQuery.
Je crois que je devrais m'orienter vers le forum base de données pour creuser ce point-là.

[Higgins]

On m'a apporté une solution dans cette discussion
Pour un puriste, la solution n'est pas idéale mais elle a le mérite de fonctionner