Pregunta:

Hay una manera fácil de obtener una lista de tipos de los recursos que se fuga en una aplicación en ejecución? IOW mediante la conexión a una aplicación ?

Sé memproof puede hacerlo, pero se ralentiza tanto que la aplicación no durar hasta un minuto. La mayoría de los taskmanager le gusta puede mostrar el número, pero no el tipo.

No es un problema de que la verificación en sí es catastrófico (se detiene la aplicación del proceso), ya que puede comprobar con un taskmgr si me estoy acercando (o al menos espero)

Cualquier otro perspectivas sobre la pérdida de recursos de caza (por lo tanto no memoria) también es motivo de satisfacción.

De fondo:

Tengo una Delphi 7/2006/2009 aplicación (compila con los tres) y después de un par de semana se comienza a actuar raro. Sin embargo, sólo en uno de los lugares que se ejecuta, en varios otros sistemas se ejecuta hasta que se va la luz.

He tratado de poner en algunos de depuración de código para limitar el problema. y encontró que la excepción es EOutofResources en una de guardar un archivo. (guardar archivo puede pasar miles de veces al día).

He intentado razón a cabo pérdidas de memoria (con fastmm), pero dado que el flujo de datos es muy elevada (60MByte/s de gigabit industrial de la cámara), sólo puedo descartar «arrastrándose» pérdidas de memoria con fastmm, no es rápido destellos de memoryleaks que escape de la memoria en torno a la vez que esto suceda. Si algo sale mal, la aplicación completa de la memoria en menos de la mitad de un minuto.,

Principales sospechosos son filehandles que están de alguna manera a la izquierda en algunos de error y TMetafiles (que se transmiten a estos archivos). Menores sospechosos son VST, popupmenu y tframes

Actualizaciones:

Otra posible sugerencia: funcionó muy bien durante dos años, D7, y ahora los problemas son con Turbo Explorer (el que yo uso para la estabilidad de los proyectos no se convierten a D2009 ).

Pablo-Ene: Ya que sólo ocurre una vez a la semana (y que puede suceder en la noche), para la adquisición de información es lento. Que es por eso que hago esta pregunta, la necesidad de combinar cosas para cuando estoy allí jueves. En resumen: no, yo no sé 100% seguro. Tengo la intención de llevar a toda la Systemtools colección a ver si puedo encontrar algo (porque entonces se estará ejecutando durante días). También existe la posibilidad de que veo los archivos abiertos. (tal vez debería tratar de encontrar algo de mingw lsof y el calendario)

Pero la app se ve muy poca GUI acción (es una visión de la máquina de inspección de la aplicación), excepto la actualización de la pantalla +/- 15/s que es tbitmap stretchdraw + tmetafile, pero me sale este error cuando se guarda en el disco (TFileStream) handles son, probablemente, realmente agotado. Sin embargo, en la misma corriente, TMetafile es también savetostreamed, algo que más tarde de las aplicaciones no tienen ya, y se puede ejecutar desde meses.

——————- ACTUALIZACIÓN

He buscado y buscado y buscado, y logró reproducir los problemas in-vitro de dos o tres veces. Los problemas que sucedió cuando memusage fue de +/- 256 MB (los sistemas de 2GB), los objetos de usuario de 200, de los objetos gdi 500, no un archivo más abierto de lo esperado ).

Esto no es realmente excepcional. Hago notar que yo fuga de pequeñas cantidades de asas, probablemente debido a reparenting marcos (algo que en la VCL parece fuga HPalette), pero sospecho que la causa es un problema diferente. Puedo volver a usar TMetafile, y .claro que en el medio. Creo que despejar el metarchivo en realidad no (siempre?) cambiar el tamaño de los recursos, finalmente, cada uno de metarchivo en el conjunto de tmetafile en su tamaño máximo, y con 20-40+ tmetafiles (que puede ser de varios 100ks cada uno) este llegará el montón del escritorio límite.

Que la teoría, pero voy a tratar de comprobar esto mediante la configuración del escritorio límite de 10 mb a los clientes, pero va a ser varias semanas antes de que tenga la confirmación si esto cambia nada. Esta teoría también se confirma por qué esta máquina es especial (es posible que esta máquina tiene naturalmente un poco más grande metarchivos en promedio). Ocasionalmente liberar y volver a crear un tmetafile en la piscina también podría ayudar.

Por suerte todos estos problemas (tanto tmetafile y reparenting) ya se han diseñado en las nuevas generaciones de las aplicaciones.

Debido a las especiales circunstancias (y el hecho de que tengo muy limitada de prueba de windows), este va a ser un tiempo, pero he decidido aceptar el montón del escritorio como un ejemplo por ahora (aunque la GDILeaks cosas también era algo útil).

Otra cosa que la auditoría reveló GDI-tipos de uso en un hilo (aunque sólo el ahorro de tmetafiles (que no se utiliza o conectado de otra manera) a los arroyos.

————- Actualización 2.

Aumentar el límite de escritorio sólo parecía minorly aumentar el tiempo hasta que se produjo el problema.

Por desgracia, no voy a ser capaz de seguir en esto más a fondo, ya que las máquinas se han actualizado a una versión más reciente de que el marco no tiene el problema.

En resumen, sólo puedo manifestar lo que las tres principales modificaciones que va desde el antiguo al nuevo marco:

  • Yo ya no cambio de pantallas reparenting marcos. Ahora trabajo con las formas que puedo ocultar y mostrar. He cambiado esto desde que yo también tenía muy raros los accidentes o excepciones (que podría ser el clic de distancia) debido a esto. Los accidentes fueron todos durante el funcionamiento de la GUI aunque no de forma espontánea como el principal problema
  • La rutina en la que el accidente ocurrió tratados con TMetafile. TMetafile ha sido diseñado, y reemplazar por una simplificación de la propia hecha formato. (básicamente matrices con Opengl vértices)
  • Dibujo no sucedió con tbitmap con un tmetafile superposición de strechdrawn sobre él, pero el uso de OpenGL.

Por supuesto que podría ser también algo más, que se cambió en la reescritura de las anteriores partes, la fijación de algunos muy desagradable detalle error. Tendría que ser muy mala, ya que analiza el sistema anterior tanto como pude.

Actualizado nov 2012 después de algún correo privado discusión: En retrospectiva, el siguiente paso habría sido añadir un contador a la metarchivos de los objetos, y simplemente crear una nueva instancia de cada x * 1000 usos o así, y a ver si eso cambia nada. Si usted tiene problemas similares, intentar ver si se puede un poco regularmente destruir y reinicializar vida larga y recursos que se asignan dinámicamente.

Mientras taskmanager no puede mostrar el tipo de identificadores que se pierden, que ayudar a confirmar si hay maneja una fuga en todos. No me queda claro si este es el caso, tal vez usted puede actualizar su respuesta con esta info?
Estoy teniendo casi exactamente el mismo problema ahora mismo, pero no hay metarchivos de los involucrados.
¿Cómo se puede cambiar de escritorio límites?
El mismo error cazas de mí por mucho tiempo.
Altar: En retrospectiva, sospecho TMetafile, o TBitmap. Para mostrarles que fueron pintados en tpanels, y, opcionalmente, fueron salvos. Sospecho que algo va mal allí. Me mudé a opengl, y el único problema que tengo no es doloroso fuente de apoyo.

OriginalEl autor Marco van de Voort | 2010-02-01

7 Comentarios

  1. 6

    Si son de GDI fugas usted puede tener una mirada en MSDN Magazine de enero de 2003 que utiliza la herramienta GDILeaks. Otras herramientas son GDIObj o GDIView. Ver también aquí.

    Otra fuente de EOutOfResources podría ser que el Montón De Escritorio es completa. Yo he tenido ese problema ocupado en los servidores de terminales con pantallas de gran tamaño.

    Si hay un montón de identificadores de archivo que se pierden se puede comprobar a cabo el Proceso Explorer y echar un vistazo a los identificadores de archivo abierto de su proceso y ver alguna fuera de lo común. O el uso de WinDbg con el !htrace comando.

    Mejor respuesta hasta ahora. Muestra los recursos GDI de acuerdo a tipo. Primero veamos cómo funciona en el cliente antes de aceptar etc
    Se puede especificar el nombre de these free tools? Porque ahora este enlace no es válido.
    He corregido el enlace y el nombre de la herramientas

    OriginalEl autor Lars Truijens

  2. 11

    Hay un slim posibilidad de que el error es engañosa. La VCL ingenuamente informes EOutOfResources si es que no se puede obtener un DC para una ventana (ver TWinControl.GetDeviceContext en Controles.pas).

    Digo «ingenuamente» porque hay otras razones por las GetDC() podría devolver un valor NULL identificador y la VCL, debe reportar el error del sistema operativo, no suponga una salida de recursos de la condición (hay una versión de Windows de verificación necesarios para que esto sea fiable posible, pero la VCL puede y debe dar de que demasiado).

    Tuve una situación en la que yo estaba recibiendo el EOutOfResources de error como el resultado de un identificador de ventana de convertirse en un inválido. Una vez que yo había descubierto el verdadero problema, la búsqueda de la causa y la fijación era simple, pero he perdido muchos, muchos horas tratando de encontrar un inexistente pérdida de recursos.

    Si es posible me gustaría examinar el seguimiento de la pila que lleva a esta excepción – si es que viene de TWinControl.GetDeviceContext entonces el problema puede no ser lo que usted piensa (es imposible decir lo que podría ser, por supuesto, pero eliminando el imposible es siempre el primer paso hacia el descubrimiento de la solución, no importa cuán improbable).

    Gran consejo. ¿Cuál puede ser la razón para GetDC para devolver un valor NULL?
    la más simple, y la que fue la captura de mí, en mi caso, es cuando el HWND pasado GetDC() no es válido. En mi caso fue una ventana que ya habían sido destruidos. Una vez que yo había descubierto este [con mi propia llamada a GetLastError()] era en realidad bastante simple para ver cómo y por qué el HWND estaba siendo [inesperadamente] destruido antes de que yo había obtenido la DC y para solucionar ese problema.

    OriginalEl autor Deltics

  3. 2

    La mayoría de las veces vi EOutOfResources, se trataba de algún tipo de pérdida de manejar.

    Intenta algo como MadExcept?

    –jeroen

    Lo sé, es por eso que estoy buscando una manera de encontrar un resourceleak tipo de resumen. Yo solía hacer esto con memproof (afaik enganchado un montón de llamadas de win32 para ello), pero que se ralentiza demasiado.
    Le sugiero que se centran en la pila de rastreo de los vertederos y la figura hacia fuera de contexto, más que de recursos de resúmenes. Sin embargo, creo que AQTime podría ser capaz de establecer un vínculo de recursos de la cuenta con líneas de código que crea, el cual podría ser útil para usted.
    MadExcept 4 tiene la capacidad de capturar las pérdidas de recursos (aplicaciones de 32 bits solamente)

    OriginalEl autor Jeroen Wiert Pluimers

  4. 2

    «He tratado de poner en algunos de depuración de código para limitar el problema. y encontró que la excepción es EOutofResources en una de guardar un archivo. (guardar archivo puede pasar miles de veces al día).»

    Estoy disparando en la oscuridad aquí, pero podría ser que usted está usando la API de Windows para (GetTempFileName) crear un archivo temporal y usted está volando fuera de algunos archivos de sistema de índices o de olvido de cerrar un identificador de archivo?

    De cualquier manera, estoy de acuerdo en que con su suposición sobre que es un identificador de archivo problema. Que parece ser el más probable cosa teniendo en cuenta los síntomas y el diagnóstico.

    No gettempfilename. Pensé acerca de filehandles de inmediato, y se comprueba. Howevera todos los principales guarda en intentar finallys en muy simple y overviewable hilo .métodos execute (todos los que comúnmente se hace guarda se concentran en un almacenamiento de hilo, ya que el bloque es demasiado largo). Ninguno de los hilos parecen a parar (lo que una excepción no controlada haría), pero se agregó el registro empieza a devolver este (a cargo) EOutofResources.

    OriginalEl autor Allen Bauer

  5. 2

    He ejecutar en este problema antes de. De lo que he sido capaz de decir, Delphi puede lanzar una EOutOfResources cualquier momento la API de Windows devuelve ERROR_NOT_ENOUGH_MEMORY, y (como las otras respuestas aquí discutir) de Windows puede devolver ERROR_NOT_ENOUGH_MEMORY para una variedad de condiciones.

    En mi caso, EOutOfResources era causada por un TBitmap – en particular, TBitmap la llamada a CreateCompatibleBitmap, la cual se usa con su valor predeterminado PixelFormat de pfDevice. Al parecer Windows puede valer bastante estricto sistema de límites en la cantidad de memoria disponible para el dispositivo dependiente de mapas de bits (véase, e.g, esta discusión), incluso si su sistema tiene un montón de memoria y un montón de recursos GDI. (Estos en todo el sistema de límites son al parecer debido a que Windows puede asignar dependiente del dispositivo de mapas de bits en la memoria de la tarjeta video.)

    La solución es simplemente para el uso independiente del dispositivo (Dib) en lugar de (aunque estos no pueden ofrecer tan buena como de la actuación). Para hacer esto en Delphi, establecer TBitmap.PixelFormat a otra cosa que pfDevice. Este artículo de KB describe cómo escoger la óptima DIB formato para un dispositivo, aunque yo generalmente uso pf32Bit en lugar de intentar determinar el formato óptimo para cada uno de los monitores de la aplicación se muestra en.

    He comprobado, y el origen de los conjuntos de todas las imágenes a pf8bit después de la creación. La reescritura de muertos tbitmap en favor de un tipo de imagen. (basado en una matriz de bytes. Así que supongo que es algo similar, pero para tmetafile.
    ¿Recuerda usted el nombre detrás «de esta lista de correo de discusión»? el enlace está muerto ahora.
    No recuerdo, pero encontré otra discusión (o de otra copia de la misma discusión) y actualizado el enlace. Gracias.

    OriginalEl autor Josh Kelley

  6. 0

    También tratar de verificación de número de identificador de la aplicación con Process Explorer de SysInternals. Manejar las pérdidas pueden ser muy peligrosas y construyen lentamente a través del tiempo.

    OriginalEl autor Runner

  7. 0

    Actualmente estoy teniendo este problema, en el software, que está claro que no es fuga de asas en mi propio código, así que si hay fugas de que podría estar sucediendo en un componente de código fuente o de la VCL código fuente en sí.

    El número de identificador y GDI y el objeto de usuario de cuenta no están aumentando, ni es algo que está siendo creado. Deltic la respuesta de la muestra de la esquina de los casos en los que el mensaje es una especie de rojo-el arenque, y Allen sugiere que incluso un archivo de escritura puede causar este error.

    Hasta ahora, La mejor estrategia que he encontrado para la caza de ellos es el uso de cualquiera de JCL JCLDEBUG pila de trazas de retorno, o el informe de excepción funciones de almacenamiento en MadExcept para generar la información de contexto para averiguar lo que realmente está fallando.

    En segundo lugar, AQTime contiene muchas herramientas para ayudarle a usted, incluyendo un perfilador de recursos que pueden mantener los vínculos entre el lugar donde el código que crea los recursos es, y de cómo se llama, junto con los recuentos del número total de asas. Se puede obtener resultados a MEDIADOS de EJECUCIÓN y por tanto no se limita a la detección de unfreed recursos después de la salida. Así, ejecutar AQTime, hacer un resultados en la captura de mediados de ejecutar, esperar varias horas, y la captura de nuevo, y usted debe tener dos puntos en el tiempo para comparar el número de identificadores. Sólo en caso de que es lo obvio. Pero como Deltics sabiamente señala que esta clase de excepción se plantea en los casos en que probablemente no debería haber sido.

    En retrospectiva, yo sospecho que era algo TMetafile relacionados.

    OriginalEl autor Warren P

Dejar respuesta

Please enter your comment!
Please enter your name here