¿Es esto una pérdida de memoria?

Question

Estoy usando el módulo gc para depurar una fuga.

Es un programa de interfaz gráfica de usuario y he conectado esta función a un botón.

he fijado establecido depurar más a gc.SAVE_ALL

> gc.collect() 
> 
> print gc.garbage 

y esta es la salida

[(<type '_ctypes.Array'>,), {'__module__': 'ctypes._endian', '__dict__': <attribute '__dict__' of 'c_int_Array_3' objects>, '__weakref__': <attribute '__weakref__' of 'c_int_Array_3' objects>, '_length_': 3, '_type_': <class 'ctypes.c_int'>, '__doc__': None}, <class 'ctypes._endian.c_int_Array_3'>, <attribute '__dict__' of 'c_int_Array_3' objects>, <attribute '__weakref__' of 'c_int_Array_3' objects>, (<class 'ctypes._endian.c_int_Array_3'>, <type '_ctypes.Array'>, <type '_ctypes._CData'>, <type 'object'>), (<type '_ctypes.CFuncPtr'>,), {'__module__': 'ctypes', '__dict__': <attribute '__dict__' of '_FuncPtr' objects>, '__weakref__': <attribute '__weakref__' of '_FuncPtr' objects>, '_flags_': 1, '__doc__': None, '_restype_': <class 'ctypes.c_int'>}, <class 'ctypes._FuncPtr'>, <attribute '__dict__' of '_FuncPtr' objects>, <attribute '__weakref__' of '_FuncPtr' objects>, (<class 'ctypes._FuncPtr'>, <type '_ctypes.CFuncPtr'>, <type '_ctypes._CData'>, <type 'object'>), {}, <cell at 0x10a24b0: Resource object at 0x10e6a50>, <cell at 0x10a2478: dict object at 0x11a4440>, <cell at 0x7f1703949f68: function object at 0x10ec7d0>, <cell at 0x10e2f30: NoneType object at 0x826880>, <cell at 0x10e2d70: NoneType object at 0x826880>, <cell at 0x10e2ef8: str object at 0x7f1703dd5e10>, <cell at 0x10e2de0: dict object at 0x118aaa0>, {'Accept': 'application/json', 'User-Agent': 'couchdb-python 0.6'}, (<cell at 0x10e2f30: NoneType object at 0x826880>, <cell at 0x10a24b0: Resource object at 0x10e6a50>, <cell at 0x10e2de0: dict object at 0x118aaa0>, <cell at 0x10a2478: dict object at 0x11a4440>, <cell at 0x10e2d70: NoneType object at 0x826880>, <cell at 0x10e2ef8: str object at 0x7f1703dd5e10>, <cell at 0x7f1703949f68: function object at 0x10ec7d0>), <function _make_request at 0x10ec7d0>, (1,), {}, <cell at 0x10e2bb0: Resource object at 0x10e6a50>, <cell at 0x10e2e88: dict object at 0x119f360>, <cell at 0x10f0130: function object at 0x10ec578>, <cell at 0x10f01d8: NoneType object at 0x826880>, <cell at 0x10f01a0: NoneType object at 0x826880>, <cell at 0x10f00f8: str object at 0x7f170b05d810>, <cell at 0x10f00c0: dict object at 0x11969a0>, {'Accept': 'application/json', 'User-Agent': 'couchdb-python 0.6'}, (<cell at 0x10f01d8: NoneType object at 0x826880>, <cell at 0x10e2bb0: Resource object at 0x10e6a50>, <cell at 0x10f00c0: dict object at 0x11969a0>, <cell at 0x10e2e88: dict object at 0x119f360>, <cell at 0x10f01a0: NoneType object at 0x826880>, <cell at 0x10f00f8: str object at 0x7f170b05d810>, <cell at 0x10f0130: function object at 0x10ec578>), <function _make_request at 0x10ec578>, (1,), {}, <cell at 0x10f0440: Resource object at 0x10e6a50>, <cell at 0x10f02b8: dict object at 0x11b2d70>, <cell at 0x10f0360: function object at 0x10ec6e0>, <cell at 0x10f0280: NoneType object at 0x826880>, <cell at 0x10f02f0: str object at 0x10ca228>, <cell at 0x10f0408: str object at 0x7f170b05d810>, <cell at 0x10f0050: dict object at 0x11b6370>, {'Accept': 'application/json', 'User-Agent': 'couchdb-python 0.6'}, (<cell at 0x10f0280: NoneType object at 0x826880>]

La lista gc.garbage tiene una gran cantidad de artículos. ¿Significa esto que los objetos en gc.garbage están goteando o han sido recolectados o serán recolectados?

Answer 1

De the docs:

gc.garbage

una lista de objetos que el colector se ha encontrado para ser inalcanzable, pero no podría ser liberado (objetos incobrables).

Parece una especie de filtración para mí. Ahora los documentos van a explicar las condiciones en que esto podría ocurrir:

objetos que tienen Del() métodos y forman parte de un ciclo de referencia causa de todo el ciclo de referencia sea incobrable, incluyendo objetos no necesariamente en el ciclo, pero solo accesible desde él. Python no recopila dichos ciclos automáticamente porque, en general, Python no puede adivinar un orden seguro para ejecutar los métodos del(). Si conoce un pedido seguro, puede forzar el problema examinando la lista de basura y rompiendo explícitamente los ciclos debido a sus objetos dentro de la lista. Tenga en cuenta que estos objetos se mantienen vivos aún en virtud de estar en la lista de basura, por lo que también deben eliminarse de la basura. Por ejemplo, después de romper los ciclos, do del gc.garbage [:] para vaciar la lista. Por lo general, es mejor evitar el problema al no crear ciclos que contengan objetos con los métodos del(), y la basura se puede examinar en ese caso para verificar que no se creen dichos ciclos.

Ahora que tiene el conjunto DEBUG_SAVEALL bandera hace todo de su fuga de basura. De la misma fuente:

gc.DEBUG_SAVEALL

Cuando se establece, todos los objetos que se encuentran fuera de cobertura será anexado a la basura en lugar de ser liberado. Esto puede ser útil para depurar un programa con fugas.

Entonces, de nuevo, sí, esa lista se ha filtrado de memoria. ¡Pero usted le dijo que goteara todo eso!

Answer 2

En otros idiomas, he utilizado un analizador de montón con gran éxito para rastrear las pérdidas de memoria. Nunca he usado uno en Python, pero Heapy parece que valdría la pena intentarlo.

En su sección "Proceso de Datos", trate de esta característica a cabo:

• Cálculo de la 'dominado' fijó de un conjunto de objetos raíz que produce el conjunto de objetos que se cancela la asignación si los objetos raíz fueron desasignados

Si es como otras herramientas, debería poder profundizar. Sigue los objetos con el "conjunto dominado" más grande hasta que encuentres algo que parezca demasiado grande, es probable que sea una filtración.