2008-11-07 20 views
7

Después de actualizar un proyecto de Delphi 2007 para Delphi 2009 Recibo un desconocido pérdida de memoria, hasta ahora he estado tratando de localizarlo usando FastMM, esto es lo FastMM informes de seguimiento de la pila:Cómo rastrear la pérdida de memoria complicada con 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 

Y a veces obtengo esto:

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 

¿Hay alguna forma mejor de descubrir qué es lo que realmente está causando la pérdida de memoria?

Respuesta

9

Esta pérdida de memoria era causado por un error de Delphi, QC #67709

Fue fijada por la última actualización de Delphi 2009, no es de extrañar que no era capaz de solucionarlo.

0

IIRC VCL tenía algunas fugas muy pequeñas como esta que puede ignorar sin mucha preocupación. Este podría ser uno de ellos? Espero que alguien aclare este punto.

1

No sé si hay fugas en VCL D2009, por lo que suponiendo el escape es en su código, en primer lugar me gustaría comprobar lo siguiente:

  • ¿hay alguna matriz o lista (debido @DynArraySetLength) creados en esa forma que no se libera cuando se deshace de la forma.
  • hay alguna función que crea y devuelve algún objeto que debería ser liberado por un llamante externo, y si tiene ese tipo de función, compruebe si el llamador libera ese objeto.
  • si esto no revela una fuga, entonces debe verificar si cada objeto que crea en el código de su formulario se destruye cuando destruye el formulario.
7

Mientras el tamaño del bloque de memoria no se filtre no crece cuanto más tiempo/más se utiliza su programa, entonces no es una preocupación. Si tiene objetos de larga vida que solo se liberan cuando finaliza la aplicación, es lo mismo que si los filtrara: toda la memoria se recupera al finalizar (a menos que, por supuesto, manejen recursos más allá de la memoria).

Las pérdidas de memoria que desea preocuparse son las que se acumulan con el tiempo o el uso. Si es 20 bytes cada vez, entonces no te preocupes.

+0

Está creando una o más pérdidas de 20 bytes para cada formulario que abro, lo extraño es que comenzó a suceder después de actualizar a Delphi 2009, sin cambiar el código. –

+0

Si es una cantidad finita, entonces no es un problema, pero si el usuario tiene la opción de abrir cada formulario varias veces, y cada apertura pierde 20 bytes adicionales, entonces tiene una pérdida de memoria lenta pero potencialmente problemática . –

+0

Con 2 GB de RAM, los usuarios tendrán que abrir alrededor de 100 millones de formularios en una sesión antes de que se les acabe la memoria física debido a esta filtración. Afortunadamente para usted, RSI limitará la cantidad de memoria que se puede filtrar por las acciones del usuario aquí :-) –

0

Diría que algo está pasando en su manejador de eventos Form OnCreate que está haciendo crecer una DynArray.
Y ese DynArray no se lanza al final.
Pero sin ver el código y realmente depurarlo con FastMM, es casi imposible adivinar lo que realmente está sucediendo.

1

La última vez que tuve una desconcertante fuga a lo largo de estas líneas revisé la memoria en bruto del objeto ofensivo y vi un texto que me mostró qué tipo de datos era. Cuando dice que no sabe qué tipo de objeto es el que probablemente significa que no es un objeto en primer lugar, así que observe las cosas dinámicamente asignadas, incluidas las cadenas.