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]
-----------------------------------------------------------------------------


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



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

Reply via email to