On 2015-03-12 06:21 PM, Matthias Schmitt wrote: > Hello, > > I know, I am touching a hot iron, when claiming that sqlite might have a > memory leak. But I am trying to debug memory leaks related to sqlite now > since 4 days and I am running against walls.
Hi Matthias, Firstly, there are no hot irons here, it either works as designed, or it doesn't. If it does work correctly, we will gladly show you the way. if it doesn't, then we will all be glad it came to light and await the fix eagerly - you are very welcome to post the concern. It is a little suspect that millions of applications around the world gets compiled and memory-leak-checked daily with sqlite and your's is the only one finding a leak - BUT, it is not impossible at all. > Here is my problem: > > - I am writing an iPhone app using iOS 8.2, Xcode 4.2, sqlite 3.8.8.3. > > - The memory leak appears in the iPhone simulator more often, than on an > original iPhone device, but it appears always. > > - The leak appears with totally different type of queries. It might be, that > a leak appears in a specific query in one debug session and in another debug > session, it doesn?t (which makes it difficult to debug and drives me totally > nuts). For me it seems to be related to a timing/threading issue. This is why > it makes not much sense to offer some code here. > > - When debugging inside sqlite the leak is always related to the same code > line, independent from the type of database command (select, insert, delete). > > - It appears always with the memory allocation in sqlite.c line 16872 in > function sqlite3MemMalloc > Here is the line: void *p = SQLITE_MALLOC( nByte ); > > - The leaked memory has always a size of nByte = 4344 bytes. > > - Here is a typical call stack up to the leaked code: This is a bit weird, how do you know the memory is leaked when you are still in the functions dealing with it? The definition of a memory leak (simplified for our purposes) is where some memory is acquired into processes repeatedly with the needed memory already existing and not released so that perpetual memory-adding will eventually eat up all the available resources. To be more succinct: It's an accumulation of allocations over time. Lots of times memory is allocated once and kept, or cached, or used by shared resources or many other things that might speed up processes. If the memory is only ever released when the object or only program structure that can use it is released/freed/disposed, then it is still ok and not a leak. If memory is retained even after the destruction of it's keeper, then it may also be regarded as a "leak", even without accumulation. I cannot see from anything you said that the memory survives the death of the object, nor that it accumulates in any way. It may well still be an unnecessary allocation, but it can't possibly be a "Leak" (unless I am misreading your information). All that said, you may well ask "What is this allocation, and should it happen?" (Which a dev might answer) - but is it hurting your program or the use thereof? (That would be a real cause for concern).
