[sqlite] Possible Memory Leak

2006-12-21 Thread Jose Miguel Goncalves 

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

2006-12-21 Thread John Stanton 
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

2006-12-21 Thread Brodie Thiesfield 
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

2006-12-21 Thread 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: 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

2006-12-21 Thread drh 
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

2007-07-02 Thread Ben Combee 

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

2018-07-29 Thread Patricia Monteiro 
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

2007-07-02 Thread drh 
"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

2007-07-02 Thread Ben Combee 

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

2018-07-29 Thread Richard Hipp 
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