This is something the Coverity caught when run locally on the SQLite
3.3.17 source, but it seems to still be there in the CVS version:
In select.c's sqlite3ResultSetOfSelect(), zName is allocated using a
malloc-style function at the top of the routine. Later, there's code
to guarantee a unique
Ben Combee [EMAIL PROTECTED] wrote:
This is something the Coverity caught when run locally on the SQLite
3.3.17 source, but it seems to still be there in the CVS version:
In select.c's sqlite3ResultSetOfSelect(), zName is allocated using a
malloc-style function at the top of the routine.
On 7/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Ben Combee [EMAIL PROTECTED] wrote:
Won't this code leak the memory to which zName points during the
assignment from the call to sqlite3MPrintf?
The %z calls sqliteFree() for you automatically.
Thanks for the clarification. One less
Your program does not free the memory malloc'd by sqlite3_errmsg by
calling sqlite3_free. I guess that Valgrind is telling you that. You
don't have to worry about Sqlite.
Jose Miguel Goncalves wrote:
Hi,
Running a simple sqlite3_open()/sqlite3_close() program (attached) I get
a report of
The API documentation doesn't mention anything about this. It would be
good to have it added there.
http://www.sqlite.org/capi3ref.html#sqlite3_errmsg
However drh stated a while ago that sqlite3_errmsg strings do NOT need
to be freed. Error strings returned from sqlite3_exec do.
John,
sqlite3_errmsg() was never executed in my example (no errors), so valgrind
could not account for memory leaks on this part of the code.
Nevertheless I've modified my program to free the error message and valgrind
still complains about 272 bytes in 2 blocks possibly lost.
But, as Brodie
Jose Miguel Goncalves [EMAIL PROTECTED] wrote:
Hi,
Running a simple sqlite3_open()/sqlite3_close() program (attached) I get a
report of a possible memory leak in valgrind:
It would appear that your implementation of pthreads is allocating
some memory to use in its implementation of thread
