Question

Après la mise à niveau d'un projet de Delphi 2007 à Delphi 2009, une fuite de mémoire inconnue s'est produite. Jusqu'à présent, j'essayais de le détecter à l'aide de fastMM. Voici les rapports de suivi de la pile de fastMM:

A memory block has been leaked. The size is: 20

This block was allocated by thread 0x111C, and the stack trace (return addresses) 
  at the time was:
40339E [System.pas][System][@GetMem][3412] 534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
562D48 [DBCommon.pas][DBCommon][TFilterExpr.PutExprNode][1583]
408E46 [System.pas][System][DynArraySetLength][20464]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]
528C1B [Forms.pas][Forms][TCustomForm.DoCreate][3260]
171A1A [GetRawStackTrace]

The block is currently used for an object of class: Unknown

The allocation number is: 302844

Et parfois je reçois ceci:

A memory block has been leaked. The size is: 20

This block was allocated by thread 0x111C, and the stack trace (return addresses) 
  at the time was:
40339E [System.pas][System][@GetMem][3412]
534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
77DC921A [RtlAnsiStringToUnicodeString]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
7726B8F5 [GetProcAddress]
7726B907 [GetProcAddress]
589B1E [ossrv.cpp][MidasLib][DllGetDataSnapClassObject][3163]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]

The block is currently used for an object of class: Unknown

Existe-t-il un meilleur moyen de déterminer la véritable cause de la fuite de mémoire?

Était-ce utile?

La solution

Cette fuite de mémoire était due à un bogue Delphi et au contrôle du # 67709

Elle a été corrigée par la dernière mise à jour de Delphi 2009, il n’est donc pas étonnant que je n’aie pas pu la résoudre.

Autres conseils

Tant que la taille du bloc de mémoire qui a fui ne croît pas plus longtemps / plus votre programme est utilisé, ce n'est pas un problème. Si vous avez des objets de longue durée qui ne sont libérés que lorsque vous arrêtez l’application, c’est la même chose que si vous les avez perdus; toute la mémoire est récupérée à l’arrêt (à moins bien sûr qu’ils aient des ressources dépassant la mémoire).

Les fuites de mémoire qui vous intéressent sont celles qui s’accumulent avec le temps ou l’utilisation. S'il s'agit de 20 octets à chaque fois, ne vous en faites pas.

Je ne sais pas s'il y a des fuites dans la VCL D2009, donc si la fuite est dans votre code, je vérifierais d'abord ce qui suit:

  • existe-t-il un tableau ou une liste (en raison de @DynArraySetLength ) créés dans ce formulaire qui n'est pas publié lorsque vous supprimez le formulaire.
  • existe-t-il une fonction qui crée et retourne un objet qui devrait être libéré par un appelant externe, et si vous avez ce type de fonction, vérifiez si l'appelant libère cet objet.
  • si cela ne révèle pas la fuite, vous devez alors vérifier si chaque objet que vous créez dans votre code de formulaire est détruit lorsque vous détruisez le formulaire.

La dernière fois que j'ai eu une fuite mystérieuse, j'ai parcouru la mémoire brute de l'objet incriminé et j'ai vu un texte qui me montrait en quelque sorte le type de données. Quand il dit qu'il ne sait pas de quel type d'objet il s'agit, cela signifie probablement qu'il ne s'agit pas d'un objet en premier lieu. Regardez donc les objets alloués de manière dynamique, y compris les chaînes.

IIRC VCL a eu quelques très petites fuites comme celle-ci que vous pouvez ignorer sans trop vous inquiéter. Cela pourrait être l'un d'entre eux !? J'espère que quelqu'un clarifie ce point.

Je dirais qu'il se passe quelque chose dans votre gestionnaire d'événements Form OnCreate qui fait pousser un DynArray.
Et que DynArray ne soit pas publié à la fin.
Mais sans voir le code et le déboguer avec FastMM, il est presque impossible de deviner ce qui se passe réellement.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top