--- Begin Message ---
- To: sqlite-users@sqlite.org
- Cc:
- Subject: Re: [sqlite] Possible Memory Leak
- From: drh@hwaci.com
- Date: Thu, 21 Dec 2006 22:21:30 +0000
- Message-id: <2454091.429485096482039577148250423352068957340736345@hwaci.com>
- Reply-to: sqlite-users@sqlite.org
- In-reply-to: <458ADFE5.40201@inov.pt>
- References: <458ADFE5.40201@inov.pt>
Jose Miguel Goncalves <jose.goncalves@inov.pt> 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 local storage.
If so, this would be outside the scope of SQLite.
>
> $ 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
-----------------------------------------------------------------------------
To unsubscribe, send email to sqlite-users-unsubscribe@sqlite.org
-----------------------------------------------------------------------------
--- End Message ---