Это утечка памяти? - PullRequest
       5

Это утечка памяти?

5 голосов
/ 23 сентября 2010

Я использую модуль gc для устранения утечки.

Это программа с графическим интерфейсом, и я подключил эту функцию к кнопке.

Я установил set debug more to gc.SAVE_ALL

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

и это вывод

[(<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>]

В списке gc.garbage много элементов. Значит ли это, что объекты в gc.garbage протекают или были собраны или будут собраны?

Ответы [ 2 ]

1 голос
/ 23 сентября 2010

С документы :

gc.garbage

Список объектов, которые сборщик счел недоступными, но не мог быть освобожден (не подлежащие сбору объекты).

Так что это выглядит как какая-то утечка для меня. Теперь документы объясняют условия, при которых это может произойти:

Объекты, имеющие дель () методы и являются частью эталонного цикла вызывает весь опорный цикл будет невозвратным, в том числе объекты, не обязательно в цикле, но достижимым только от него. Python не собирает такие циклы автоматически, потому что, как правило, Python не может угадать безопасный порядок запуска методов del (). Если вы знаете безопасный порядок, вы можете форсировать проблему, изучая список мусора и явно прерывая циклы из-за ваших объектов в списке. Обратите внимание, что эти объекты остаются живыми даже благодаря тому, что находятся в списке мусора, поэтому их также следует удалять из мусора. Например, после прерывания циклов выполните del gc.garbage [:], чтобы очистить список. Как правило, лучше избегать этой проблемы, не создавая циклы, содержащие объекты с помощью методов del (), и в этом случае можно проверить мусор, чтобы убедиться, что такие циклы не создаются.

Теперь с установленным флагом DEBUG_SAVEALL все вашей утечки мусора. Из того же источника:

gc.DEBUG_SAVEALL

Если установлено, все недостижимые объекты будут добавляться к мусору, а не освобождаться. Это может быть полезно для отладки текущей программы.

Итак, опять же, да, этот список - утечка памяти. Но вы сказали что все это пропущено!

0 голосов
/ 23 сентября 2010

На других языках я с большим успехом использовал профилировщик кучи для отслеживания утечек памяти.Я никогда не использовал его в Python, но Heapy , похоже, стоило бы попробовать.

В разделе «Обработка данных» опробуйте эту функцию:

  • Вычисление «доминирующего» набора из набора корневых объектов, который дает набор объектов, которые были бы освобождены, если бы корневые объекты были освобождены.

Если это подобно другим инструментам,Вы должны быть в состоянии сверлить.Следите за объектами с самым большим «доминирующим множеством», пока не найдете что-то, что кажется слишком большим, что, вероятно, утечка.

...