Hi, On Mon, Oct 03, 2005 at 09:02:38AM -0400, [EMAIL PROTECTED] wrote: > You are right: this is not a real memory leak. > [..]
in fact, for a program which is eg. continously using mktemp() (or a simmilar but not unsecure api) for creating temporary databases it is a real memory leak, because the hash table will grow one entry for every temporary database created. > [..] just so that the output of a diagnostic tool could look nicer. what about an sqlite3_cleanup() function which does such cleanups? then it would add no overhead at all to the library. Right now it is impossible for a host application to do such cleanups because the allocated memory is only referenced by static variables in os_unix.c. I could provide a patch which adds an sqlite3_cleanup() api. it would even possible to put that code path into a seperate elf section so it is not paged into the physical memory unless it actually is used by the application, if the incrased code size would be your next argument. but I think that this would be overkill. yours, - clifford -- ____ ___ ____ _ __ _ _ www.rocklinux.org | _ \ / _ \ / ___| |/ / | | (_)_ __ _ ___ __ | |_) | | | | | | ' / | | | | '_ \| | | \ \/ / | _ <| |_| | |___| . \ | |___| | | | | |_| |> < |_| \_\\___/ \____|_|\_\ |_____|_|_| |_|\__,_/_/\_\
