Re: [sqlite] Possible Memory Leak

[Jose Miguel Goncalves]

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 said, there's nothing on the documentation telling that 
sqlite3_errmsg() allocates memory to return data, so I've forced an error 
(trying to open a database on a filesystem without write access) and I got this:

OPEN error[14]: unable to open database file
*** glibc detected *** free(): invalid pointer: 0x00002b3cd242a5e2 ***

So, I've confirmed that sqlite3_errmsg() returns a pointer to static data and 
my question still remains about this possible memory leak.

José Gonçalves

Brodie Thiesfield wrote:
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.
http://www.mail-archive.com/sqlite-users@sqlite.org/msg16634.html

Regards,
Brodie

John Stanton wrote:
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 a possible memory leak in valgrind:

$ valgrind --leak-check=full ./test_sqlite
==11992== Memcheck, a memory error detector.
==11992== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et 
al.
==11992== Using LibVEX rev 1658, a library for dynamic binary 
translation.
==11992== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==11992== Using valgrind-3.2.1-Debian, a dynamic binary 
instrumentation framework.
==11992== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et 
al.
==11992== For more details, rerun with: -v
==11992==
OPEN OK
CLOSE OK
==11992==
==11992== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==11992== malloc/free: in use at exit: 272 bytes in 2 blocks.
==11992== malloc/free: 114 allocs, 112 frees, 14,382 bytes allocated.
==11992== For counts of detected errors, rerun with: -v
==11992== searching for pointers to 2 not-freed blocks.
==11992== checked 16,889,208 bytes.
==11992==
==11992== 272 bytes in 2 blocks are possibly lost in loss record 1 of 1
==11992==    at 0x4A1AB81: calloc (vg_replace_malloc.c:279)
==11992==    by 0x400EA3D: _dl_allocate_tls (in /lib/ld-2.3.6.so)
==11992==    by 0x4EC3500: pthread_create@@GLIBC_2.2.5 (in 
/lib/libpthread-2.3.6.so)
==11992==    by 0x4B4A427: (within /usr/lib/libsqlite3.so.0.8.6)
==11992==    by 0x4B4A5F0: (within /usr/lib/libsqlite3.so.0.8.6)
==11992==    by 0x4B4E133: sqlite3pager_open (in 
/usr/lib/libsqlite3.so.0.8.6)
==11992==    by 0x4B385CC: sqlite3BtreeOpen (in 
/usr/lib/libsqlite3.so.0.8.6)
==11992==    by 0x4B48CC6: sqlite3BtreeFactory (in 
/usr/lib/libsqlite3.so.0.8.6)
==11992==    by 0x4B495C5: (within /usr/lib/libsqlite3.so.0.8.6)
==11992==    by 0x4006F4: main (in /home/jmpg/mtm2006/tmp/test_sqlite)
==11992==
==11992== LEAK SUMMARY:
==11992==    definitely lost: 0 bytes in 0 blocks.
==11992==      possibly lost: 272 bytes in 2 blocks.
==11992==    still reachable: 0 bytes in 0 blocks.
==11992==         suppressed: 0 bytes in 0 blocks.
==11992== Reachable blocks (those to which a pointer was found) are 
not shown.
==11992== To see them, rerun with: --show-reachable=yes

Is this a "real" memory leak or may I ignore this?
Anyone has noticed this?
I'm running Debian etch, with sqlite v3.3.8.

José Gonçalves


------------------------------------------------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <sqlite3.h>

int
main(void)
{
    sqlite3        *db = NULL;
    int             ret;

    printf("OPEN ");
    ret = sqlite3_open("test.db", &db);
    if (ret != SQLITE_OK) {
        printf("error[%d]: %s\n", ret, sqlite3_errmsg(db));
        return (EXIT_FAILURE);
    }
    printf("OK\n");

    printf("CLOSE ");
    ret = sqlite3_close(db);
    if (ret != SQLITE_OK) {
        printf("error[%d]: %s\n", ret, sqlite3_errmsg(db));
        return (EXIT_FAILURE);
    }
    printf("OK\n");

    return (EXIT_SUCCESS);
}



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------