Cómo depurar la pérdida de memoria donde las instancias de excepción en el volcado heap no tienen referencias entrantes?

He estado intentando diagnosticar una pérdida de memoria en una aplicación de Android que estoy escribiendo. Tengo un volcado de montón cargado en Eclipse, pero los resultados que estoy viendo son muy curiosos. Hay aproximadamente 20.000 instancias de una excepción (específicamente, LDAPException de la biblioteca UnboundID LDAP) en el montón sin referencias de entrada.

Es decir, aparecen en la raíz del árbol dominador. Los SELECT objects e FROM com.unboundid.ldap.sdk.LDAPException e WHERE (inbounds(e).length = 0) OQL SELECT objects e FROM com.unboundid.ldap.sdk.LDAPException e WHERE (inbounds(e).length = 0) devuelve más de 20.000 resultados, totalizando casi todo el montón. Y sin embargo, el GC se ejecuta antes de la descarga de pila y puedo ver que se está ejecutando en la consola, repetidamente, durante la ejecución del código de fugas. Si estas instancias no tienen refs entrantes, ¿qué podría mantenerlas vivas?

También intenté hacer una "ruta más corta a GC" consulta. Muestra una fila LDAPConnectionReader que retiene 2 instancias y ~ 20k LDAPException @ <addr> unknown filas LDAPException @ <addr> unknown con varias direcciones hexadecimales.

Actualización : No he tenido tiempo para diagnosticar más esto desde su publicación, y la recompensa que publiqué está terminando antes de que lo haga. Lo estoy concediendo lo mejor que puedo ahora, no sea que los puntos se vayan a perder. Gracias a todos los que miraron en esto! Volveré más tarde y actualizaré de nuevo con los resultados del diagnóstico adicional, cuando la vida es un poco menos agitada.

Sea o no estas excepciones están siendo lanzadas, en términos de uso de la memoria, ese detalle es bastante irrelevante.

Mientras que le gustaría ver en el depósito de pila que tiene las referencias, por alguna razón, no eres capaz de llegar a esto. Me pregunto si el código nativo sería simbolizado correctamente en la herramienta de volcado heap?

De cualquier manera, como algo nuevo para probar, sugeriría no depurar el punto en el que se lanzan estas excepciones, pero donde se crean . Poner puntos de interrupción en la clase y / o todos sus constructores. Lo ideal sería obtener esta información de las referencias de volcado de montón, pero todavía puede resultar informativo si usted puede ver que está construyendo estos objetos repetidamente … Supongo que vienen del mismo lugar.

Si está utilizando Eclipse, puede agregar un punto de interrupción en la LDAPException . Aquí puede encontrar un tutorial sobre cómo establecer uno: Eclipse Tip: Breakpoint on Exception .

Estos puntos de interrupción interrumpen la ejecución siempre que se lance una excepción del tipo seleccionado. Una vez que encuentre las condiciones que lanzan tantas excepciones, puede arreglar el error.

No es exactamente la depuración por qué las excepciones no referenciadas están llenando el montón, pero espero que pueda ayudar.

No estoy familiarizado con OQL, o la plataforma Android en particular, o el funcionamiento interno de Java GC en esa plataforma, pero lo más obvio para mí es la falta de metadatos LDAPException . Tiene códigos de error, mensajes, métodos, etc … ¿Dónde está? ¿No se inicializó? Se le impide publicar todas esas cosas? Algo como un servidor de redireccionamiento a sí mismo podría hacerme decir "oh, eso es raro, pero un poco sentido".

¿Has intentado cambiar este lib para el JDK ? Parece que eso debería ser fácil si es posible.

Entonces empezaría a apretar el montón de todo lo que tiene. Las características del GC podrían proporcionar pistas. ¿Hay casos que escapan a la recolección de alguna manera? ¿Cuántos se crean por segundo? ¿Qué fracción de rancio son gc'd cada paso, o es una cantidad constante? ¿Están siendo creados en un bucle ocupado como Danny estaba hablando? ¿Qué pasa si llama a System.gc() en un bucle de ocupado?

Pero sí, ahí es donde empiezo la depuración de impresión. Esperemos que haya una mejor solución. :-PAG

  • AdView causa pérdida de memoria
  • Mi aplicación Android consume demasiada memoria
  • Esta clase Handler debe ser estática o pueden producirse fugas: handler final
  • ¿Cómo puedo saber cuánta memoria heap en un momento dado?
  • Admob Memory Leak - evitando usar la actividad vacía
  • Fuga de AdActivity en AdMob (SDK 7.0) para Android
  • Fuga de memoria de Android en JarURLConnectionImpl de Apache Harmony?
  • Fuga de memoria de Android entre las actividades
  • Java.lang.OutOfMemoryError: tamaño de mapa de bits supera el presupuesto de VM
  • ¿Cómo puedo solucionar esta pérdida de memoria de Android que involucra Threads?
  • ¿Puede un oyente de ViewTreeObserver no eliminado causar fugas de memoria?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.