[sqlite] Possible Memory Leak
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 #include #include 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] -
Re: [sqlite] Possible Memory Leak
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 #include #include 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] -
Re: [sqlite] Possible Memory Leak
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 #include #include 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] -
Re: [sqlite] Possible Memory Leak
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: 0x2b3cd242a5e2 *** 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 #include #include 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] -
Re: [sqlite] Possible Memory Leak
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 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 [EMAIL PROTECTED] -
[sqlite] Possible memory leak in select.c
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 name: /* Make sure the column name is unique. If the name is not unique, ** append a integer to the name so that it becomes unique. */ for(j=cnt=0; j
[sqlite] Possible memory leak in shell.c
I've been testing the latest version of SQLite with 3 static analysis tools (Infer, Clang Static Analyzer and Cppcheck) and they all reported a memory leak error in shell.c . The Infer error report is as follows: shell.c:585: error: MEMORY_LEAK memory dynamically allocated by call to `realloc()` at line 585, column 15 is not reachable after line 585, column 7. 583. if( n+100>nLine ){ 584. nLine = nLine*2 + 100; 585. > zLine = realloc(zLine, nLine); 586. if( zLine==0 ) return 0; 587. } This error occurs because if the realloc function fails the memory previously pointed out by zLine becomes inaccessible, you need to ensure that realloc! = NULL before doing zLine = realloc (zLine, nLine). ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Possible memory leak in select.c
"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. Later, there's code > to guarantee a unique name: > > /* Make sure the column name is unique. If the name is not unique, > ** append a integer to the name so that it becomes unique. > */ > for(j=cnt=0; j if( sqlite3StrICmp(aCol[j].zName, zName)==0 ){ > zName[nName] = 0; > zName = sqlite3MPrintf("%z:%d", zName, ++cnt); > j = -1; > if( zName==0 ) break; > } > > 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. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Possible memory leak in select.c
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 possible problem. Just for reference, Coverity had found about 20 issues. On inspection, I found all of them to be false except for this one and for the UTF-8 issue that's already fixed in 3.4.0. Now I know this is false too :) - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Possible memory leak in shell.c
On 7/29/18, Patricia Monteiro wrote: > I've been testing the latest version of SQLite with 3 static analysis tools > (Infer, Clang Static Analyzer and Cppcheck) and they all reported a memory > leak error in shell.c . The shell code has now been modified so that it calls exit(1) if realloc() ever returns NULL. I think it was probably already doing this, eventually, but perhaps not quickly enough for your static analysis tools to figure that out. So I've adjusted the code so that it dies quickly and unambiguously now. Hopefully this will be enough of a hint to your static analysis tools to get them to stop complaining. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users