Объект target-c не получает освобождение: ed

У меня проблема с объектом, который не освобождается в target-c. Я почти уверен, что это потому, что он где-то сохраняется, но я не знаю, где (проверка continueCount, где он должен быть 0, возвращает 1). Я много раз просматривал свой код, но не видел, что его сохраняет, чего я не выпускаю. Может быть, это даже ошибка в фреймворках, которые я использую.

Как бы вы справились с чем-то подобным? Я подумал, может быть, вы могли бы порыться в памяти и посмотреть, что указывает на этот объект, что значительно облегчит понимание того, почему он такой, но я не совсем уверен, как этого добиться. Может другое решение?


person quano    schedule 21.09.2009    source источник


Ответы (3)


Пробовали ли вы инструменты?

person Chris McCall    schedule 21.09.2009
comment
Вау, спасибо. Я совсем забыл об этом приложении. И как это ни странно, как только я начал отлаживать свою программу с помощью инструментов и не увидел никаких ошибок, сразу же стал вызываться Dealloc. :с - person quano; 21.09.2009
comment
О человек-инструменты, черт возьми, круто! На самом деле не использовал его до сих пор, но это очень полезно. - person quano; 21.09.2009

Инструменты отлично подходят и могут обнаруживать просочившиеся объекты, если и когда они просочились, но в таких случаях я предлагаю вам сначала использовать Статический анализатор Xcode, новое в Xcode 3.2 с Snow Leopard. (Если вы используете Leopard, вы можете использовать версию командной строки.) Статический анализ позволяет вы можете найти очень много проблем, даже не выполняя свой код, и во многих случаях его намного проще использовать, чем инструменты.

person Quinn Taylor    schedule 21.09.2009
comment
Я слышал, clang не работает с obj-c++. Статический анализатор Xcode делает это? Если это произойдет, я серьезно подумываю о переходе на Snow Leopard. - person quano; 21.09.2009
comment
Статический анализатор Xcode является статическим анализатором Clang, только с лучшей интеграцией с IDE, и оба используют Clang в качестве внешнего синтаксического анализатора. Clang пока не работает с C++, но прогресс неуклонно идет. clang.llvm.org/cxx_status.html Поскольку сам Clang написан на C++, я конечно, вы можете себе представить, насколько авторы привержены поддержке языка. :-) - person Quinn Taylor; 22.09.2009
comment
Тем не менее, следует отметить, что поддержка Objective-C замечательна, и что один только инструмент может сэкономить вам бессчетное количество часов на отслеживание источника утечек памяти. - person Quinn Taylor; 22.09.2009
comment
Что ж, я думаю, что пока буду придерживаться инструментов, а позже перейду на Snow Leopard. :) Спасибо за совет. - person quano; 22.09.2009

Переопределите -retain и -release, затем установите точки останова, чтобы увидеть, кто их вызывает.

person Darren    schedule 21.09.2009
comment
Я где-то видел это решение, и оно кажется очень простым и хорошим решением. Но как я узнаю, кто призывает освободить и удержать? Единственный аргумент — это self? - person quano; 21.09.2009
comment
Это может помочь выяснить, кто звонит им, но не так много, кто не звонит — вам все равно придется выяснить это самостоятельно. Xcode Static Analyzer — гораздо более элегантный и безболезненный подход, и он хорошо работает в большинстве случаев, поскольку большинство утечек происходит из-за выделения и неправильного освобождения объекта перед передачей его кому-то другому и т. д. - person Quinn Taylor; 21.09.2009
comment
Вы спрашивали Но как я узнаю, кто призывает освободить и удержать? Если вы установите точки останова в -retain и -release, то, когда эти точки останова сработают, вы сможете изучить стек вызовов, который покажет вам, кто вызвал сохранение/освобождение. - person jarmod; 29.10.2010