mémoire insuffisante à l'execution

Version imprimable

19/04/2012, 18h43
frantzgac

mémoire insuffisante à l'execution

bjr

le message d'erreur "mémoire insuffisante" apparait à l'ouverture d'une fiche (TForm) dans une application. L'ennui c'est qu'il se produit uniquement sur certains ordinateurs (deux clients distincts) et généralement après une séquence d'une dizaine d'ouverture/fermeture de la fiche.

J'ai vérifié les paramètres de mémoire virtuelle des PC concernés
J'ai exécuté l'application compilée en mode CodeGuard (sur le mien où l'erreur n'apparait pas)
J'ai vérifié les ressources Windows consommées (sur le mien toujours)
J'ai cherché à reproduire l'erreur sur toutes les machines passant par ems mains sans succès.

Sans trouver aucune erreur.

Je recherche l'origine du problème bien sûr, mais à ce stade je suis demandeur de méthodes car il me semble avoir "tout essayé".

Quel type de "trace" je pourrais mettre en œuvre, quel paramètre mesurer, pour déceler la ressource qui flanche ?
19/04/2012, 20h25
koala01

Salut,

A lire la description, j'aurais presque tendance à croire à une fuite mémoire :aie:

Il faudrait donc mettre en place un "compteur de constructeurs et de destructeurs" qui pourrait mettre les éventuelles fuites mémoire en évidence ;)

En attendant, tu peux déjà t'assurer qu'il y a bien un delete (respectivement delete[] )pour chaque new (respectivement new[] ) appelé ou t'inspirer de l'article (déjà assez ancien) de Laurent Gomilla ;)
20/04/2012, 19h42
frantzgac

Citation:

Envoyé par koala01

Salut,

A lire la description, j'aurais presque tendance à croire à une fuite mémoire :aie:

oui, j'y ai pensé mais je croyais que CodeGuard détectait ce genre de fuite ?

Citation:

Envoyé par koala01

Il faudrait donc mettre en place un "compteur de constructeurs et de destructeurs" qui pourrait mettre les éventuelles fuites mémoire en évidence ;)

En attendant, tu peux déjà t'assurer qu'il y a bien un delete (respectivement delete[] )pour chaque new (respectivement new[] ) appelé

oui, c'est bien sûr la dessus que j'ai usé mes yeux, c'est justement parce que je n'y ai rien trouvé que je botte en touche sur le forum

Citation:

Envoyé par koala01

ou t'inspirer de l'article (déjà assez ancien) de Laurent Gomilla ;)

Volontiers, je vais essayer de trouver cet article

Merci
20/04/2012, 20h00
JolyLoic

Avec des outils comme process explorer, tu peux afficher les ressources prises par un process. Pas uniquement la mémoire, mais aussi d'autres apparentées (handle de fenêtre, threads...). Peut-être que ça te donnera des idées.

Essaye aussi d'autres outils comme CodeGuard, chacun a ses forces et ses faiblesses, et on ne sait jamais, l'un peut voir ce qui échappe à l'autre.

Parfois une revue de code par une personne extérieure ayant un regard neuf peut aussi aider.
05/05/2012, 16h14
frantzgac

Oui Codeguard je l'avais essayé mais sans succès (c'est à dire qu'il ne trouvait aucune fuite ce qui est tout de même rassurant).

Process Explorer est intéressant mais on on constate une augmentation de la mémoire "Private Bytes" sans qu'il y ait de "fuite".

En revanche je n'avais pas activé CodeGuard sur les librairies liées au projet et dans l'une d'elles il y avait effectivement un destructeur mal codé. je suppose que mon bogue vient de là mais je devrais attendre la campagne de tests pour considérer le problème comme résolu.

Enseignement : penser à utiliser codeguard même sur les librairies liées au projet. Basique mais pourtant ...
01/09/2013, 21h47
frantzgac

Suite ... un an plus tard le problème persiste. Heureusement qu'il ne se manifeste que sur que peu de postes de travail. Les différentes précautions prise n'y changent rien.
03/09/2013, 11h22
white_tentacle

Citation:

Envoyé par frantzgac

Suite ... un an plus tard le problème persiste. Heureusement qu'il ne se manifeste que sur que peu de postes de travail. Les différentes précautions prise n'y changent rien.

CodeGuard ne détecte probablement pas les fuites car la mémoire reste référencée, c’est à dire qu’elle n’est pas vraiment perdue, mais pas libérée non plus.

C’est le cas si typiquement tu gardes quelque part une liste de pointeurs vers tes forms même une fois qu’elle ont été fermées mais pas détruites.

L’autre possiblité (plus moche, plus complexe à corriger) serait qu’il y ait une grosse fragmentation mémoire qui empêche l’os de libérer la mémoire, même si tu la libères du côté du programme.

Dans tous les cas, la première étape serait pour moi d’analyser un dump mémoire complet du processus, de voir quels types d’objets utilisent la mémoire, etc…
08/09/2013, 00h34
frantzgac

Piste intéressante.

Les "forms" concernées sont bien libérées par Release mais la doc dit ceci

Citation:

void __fastcall Release(void);

Description

Utilisez la méthode Release pour détruire la fiche et libérer la mémoire associée.

Release ne détruit pas la fiche avant que tous les gestionnaires d'événements de la fiche et des composants de la fiche n'aient eu le temps de terminer leur exécution. Tous les gestionnaires d'événements de la fiche ou ses enfants doivent utiliser Release. Sinon, des erreurs d'accès à la mémoire se produiront.

Remarque*: Release retourne immédiatement à l'appelant. Elle n'attend pas que la fiche soit libérée

Une partie de ce texte ne me cause pas

Citation:

Tous les gestionnaires d'événements de la fiche ou ses enfants doivent utiliser Release. Sinon, des erreurs d'accès à la mémoire se produiront.

Comment les gestionnaires d'évènements peuvent ils "utiliser" Release ?

Par ailleurs l'analyse complète de la mémoire est assez difficile dans la mesure ou le problème se produit uniquement en clientèle 4/5 fois par semaine dans le pire des cas. Qui plus est je ne sais pas comment introduire dans le code ce qui est nécessaire pour produire un dump à ce moment précis. Je veux bien l’apprendre mais je ne voudrais pas abuser ...
09/09/2013, 10h15
white_tentacle

Citation:

Envoyé par frantzgac

Par ailleurs l'analyse complète de la mémoire est assez difficile dans la mesure ou le problème se produit uniquement en clientèle 4/5 fois par semaine dans le pire des cas. Qui plus est je ne sais pas comment introduire dans le code ce qui est nécessaire pour produire un dump à ce moment précis. Je veux bien l’apprendre mais je ne voudrais pas abuser ...

Logiquement, il faut que tu installes les debugging tools for windows (trouvables chez microsoft), sur le serveur de production (évidemment, il faut que le client soit d’accord…). Ensuite, quand ça plantera, ça te proposera de créer un dump. Mais tu peux aussi en créer un avant que ça plante en t’attachant, directement depuis windbg.

Ça fait quelques années que je n’ai plus fait ça, donc je ne pourrai pas te donner la marche détaillée, mais il y a pas mal de lecture là-dessus chez microsoft, dans la doc de windbg.

Sinon pour les TForms --> c’est du borland, jamais touché un tantinet sérieusement à ça.

Solution en vue

Du nouveau sur ce problème résistant. A l'aide de journaux d'exceptions j'ai réussi à localiser le lieu exact où elle se déclenche.

ibq est un TIBQuery qui est connecté à une base Firebird
TRvLoc est un objet maison
ListRvLoc un TListObject
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 try { ibq->Open(); while (!ibq->Eof) { rvl=new TRvLoc(); ListRvLoc->Add(rvl); ... ibq->Next(); } // while ibq->Close(); } // try catch (...) { try { throw Exception(...
Il y a des allocations d'objets en mémoire assez important (typiquement 500 itérations qui instancient près de 30*500 objets).

J'ai récemment trouvé cette piste Desktop Heap qui s'est avéré une fausse piste.

J'ai analysé la consommation mémoire avec file:///i:/Download/Windows/DesktopH...8_1_2925_0.exe et j'ai constaté que la consommation mémoire restait très raisonnable.

Pour produire l'exception sur mon PC (plus musclé que celui du client et l'exception n'y survient jamais) j'ai bricolé la requête pour lire 15000 enregistrements d'un coup. A la seconde lecture (car on relit tout à chaque action importante sur l'interface utilisateur) l’exception est enfin apparue et j'ai pu constater qu'elle se produisait au moment du Next() et non du TListObject->Add() !

Je l'ai fait disparaitre en installant un FetchAll() après Open.

Cette piste me semble assez prometteuse et je vous tiendrai au courant car l'exception "Mémoire insuffisante" n'est jamais associée à la stratégie de lecture d'une requête dans les nombreux articles que j'ai trouvé sur le Net