Hi,
> I'm thinking whether this is a memory leak or not sort of depends on
> your definition. If a process is designed to remain open for long
> periods of time with little activity, and it ends up taking up 1
> gigabyte of memory, that looks an awful lot like a leak to me. There
> are likely to be at least three instances of this application running,
> and after they all run for a month, they're likely to be consuming 5
> gigabytes of memory. This is not acceptable. If SQLite's sorted
> query is taking up 2.5 megabytes of memory every time this piece of
> the application is invoked, I need to know how to ensure that that
> memory is released.
Most probably SQLite does release malloc'ed memory using free(). Note however
that free() merely notifies the C runtime the free'd piece of memory is not
used anymore. The C runtime does not necessarily release this piece of memory
to the system. That would be inefficient. As a result, the process appears to
be still using the memory. That's why tools such as 'top' on Unix are not
necessarily appropriate to detect memory leaks, they show memory still being
used by a process, although the program has called free(). The C runtime might
give memory back to the system when the system is short on memory, or unused
memory may be swapped to disk. This is a C runtime issue, not an SQLite issue.
As already explained, it could indeed be that the memory footprint is a
problem for you, but a memory footprint problem is not a memory leak:
http://en.wikipedia.org/wiki/Memory_leak
--
Dimitri
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
