Hi, Matt

I also have an iPhone app which directly interacts with sqlite using its C 
language API.  So, a few questions for you, to get a better idea of what?s 
happening:

Are you interacting directly with sqlite?  Or are you using a 3rd party API 
such as FMDB?  I take it you are not using Core Data (which optionally can use 
a sqlite database as a datastore.)

Are you using ARC?  For the uninitiated, ARC stands for Automatic Reference 
Counting.  It is an option which can be enabled on a per project basis.  Files 
within the project can opt out of using it.  ARC, reduces the amount of memory 
management code the developer has to write, but it does not license the 
developer to design unwisely.  For instance, it is still the developer?s 
responsibility to design in such a way that such things as retain cycles are 
avoided.

Have you implemented the -(void)dealloc method for all your Objective-C (or 
Swift?) objects?  I have had some success getting memory released by 
implementing -(void)dealloc and within that implementation setting specific 
objects to nil.  Note that under ARC you are not allowed to call [super 
dealloc] directly but you still can implement the -(void)dealloc method.

Are you willing to share some of your application code where it interacts with 
the sqlite database?



> On Mar 13, 2015, at 5:13 AM, Matthias Schmitt <freak002 at mmp.lu> wrote:
> 
> Hello,
> 
> thank you for your fast response.
> 
>> On 12 Mar 2015, at 17:35, Richard Hipp <drh at sqlite.org> wrote:
>> 
>> Let's start with the basics:  How do you know that the memory was in
>> fact leaked and is not instead simply being held for reuse?
> 
> The Xcode development environment comes with a debugging tool named 
> ?Instruments? which is able to detect memory leaks quite reliable. It traces 
> all references to code segments. If a reference to a code segment is 
> overwritten with a new value, but the previously addressed memory segment was 
> not released, then the software detects this as a leak. The same thing is 
> true when a variable created inside a code block references allocated memory. 
> When the program leaves the code block without releasing the previously 
> allocated memory, the reference get inaccessible and the allocated memory 
> cannot be released any more.
> 
>> On 12 Mar 2015, at 17:31, Simon Slavin <slavins at bigfraud.org> wrote:
>> Is it, by any chance, always the first SQL command executed after doing 
>> sqlite3_open() ?
> 
> No, there are multiple memory leaks which add over time.
> 
>> Is there any chance you can look at this memory and see what appears there ?
> 
> Here is an example. But different leaked memory segments look different.
> 
> <0x7fc2938b5600>
> 
> 5600: 00000072 2b9d271d
> 5608: c9b753a9 bfbc7557
> 5610: dadb57e5 cffoeefb
> 5618: db68dd48 09aa68da
> 5620: aad489da b44f4329
> 5628: dd3ba2ff 00f0ff00
> 5630: 3a653236 a9b72d6a
> 5638: 9d8ceaae 7571942b
> 5640: 51f251fe ed6bcc73
> 5648: 3a2d224a 72d43bbd
> 5650: e9fb96a8 c496a4a8
> 5658: 57a53a82 96aac489
> 5660: da9ebd2a 1fbb5657
> 5668: 6ff1536e e6713d4f
> 5670: e0ff00c2 ed73e2ff
> 5678: 008f74df 046883ca
> 
>> Do the extra 4344 bytes get included in the number shown by 
>> "sqlite3_memory_used()" ?  You could try using that function after 
>> sqlite_close() and see what it shows.
> 
> I am closing and reopening the database now after every transaction. 
> sqlite3_memory_used() shows always 0. I guess that sqlite is telling me by it 
> that it is not aware of any lost memory, correct?
> 
>> Is the memory released at any later time ?  When you use _close() on the 
>> connection, for example ?  Or, if you can track it, when SQLite calls 
>> "sqlite3_db_release_memory()" internally ?
> 
> 
> The closing and re-opening the database does not change anything in the 
> display of ?Instruments?. The program still reports memory leaks. In another 
> attempt I tried to compile the code with SQLITE_ENABLE_MEMORY_MANAGEMENT 
> compile-time option. Then I tried to call sqlite3_release_memory() after 
> every database command. Same result.
> 
> Best regards
> 
> Matthias Schmitt
> 
> magic moving pixel s.a.
> 23, Avenue Grande-Duchesse Charlotte
> L-3441 Dudelange
> Luxembourg
> Phone: +352 54 75 75
> http://www.mmp.lu
> 
> 
> 
> 
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Gregory Moore
thewatchfulone at gmail.com



Reply via email to