iOS APP With ARC no leaking but live bytes increasing

return poetry; -- I'm not convinced that returning like that will cause the @finally clause to execute. And certainly the sqlite3_finalize(statement); statement does not get executed.

What I have realized so far, IF there is a private instance variable on view controller and you pop it, the view controller is not being deallocated. In other words, dealloc method of the view controller is not being called once you have a private instance variable. For instance you have a UIView *_v , and NSTimer *_t as a private instance variable like below:

@implementation MyViewController{    UIView *_v;    NSTimer *_t;}

What I'm doing is to make them nil just before popping the view controller from view hierarchy. I think ARC will still be able to deallocate MyViewController sometime after it needs memory.

You have some questions that are going to be tough to answer.

Because of some enthusiasts' help, I narrow down my problem to the codes about fetching data from sqlite3. What is wrong with these code?

For Sqlite and debug builds:

1. ensure NDEBUG is not defined
2. ensure DEBUG is defined
3. use SQLITE_DEBUG preprocessor
4. use SQLITE_MEMDEBUG preprocessor

Otherwise, SQLite goes into 'release' mode automatically (from sqlite3.c, line 14816):

#if !defined(NDEBUG) && !defined(SQLITE_DEBUG)# define NDEBUG 1#endif

Also, from sqlite3.c, line 7780:

/*** Exactly one of the following macros must be defined in order to** specify which memory allocation subsystem to use.****     SQLITE_SYSTEM_MALLOC          // Use normal system malloc()**     SQLITE_WIN32_MALLOC           // Use Win32 native heap API**     SQLITE_ZERO_MALLOC            // Use a stub allocator that always fails**     SQLITE_MEMDEBUG               // Debugging version of system malloc()**** On Windows, if the SQLITE_WIN32_MALLOC_VALIDATE macro is defined and the** assert() macro is enabled, each call into the Win32 native heap subsystem** will cause HeapValidate to be called.  If heap validation should fail, an** assertion will be triggered.**** If none of the above are defined, then set SQLITE_SYSTEM_MALLOC as** the default.

You can also use SQLITE_CONFIG_MALLOC to sqlite3_config to use Xcode's memory manager if needed. Take a look at sqlite3_mem_methods. It may help with tracking.Also, be sure you are calling sqlite3_free on error message strings from SQLite.

Finally, you can query SQlite for its memory statistics (from sqlite3.c, line 1550):

** [[SQLITE_CONFIG_MEMSTATUS]] <dt>SQLITE_CONFIG_MEMSTATUS</dt>** <dd> ^This option takes single argument of type int, interpreted as a** boolean, which enables or disables the collection of memory allocation** statistics. ^(When memory allocation statistics are disabled, the** following SQLite interfaces become non-operational:**   <ul>**   <li> [sqlite3_memory_used()]**   <li> [sqlite3_memory_highwater()]**   <li> [sqlite3_soft_heap_limit64()]**   <li> [sqlite3_status()]**   </ul>)^** ^Memory allocation statistics are enabled by default unless SQLite is** compiled with [SQLITE_DEFAULT_MEMSTATUS]=0 in which case memory** allocation statistics are disabled by default.** </dd>