Hi,
I'm Sandro Furieri, developer and maintainer of libspatialite:
https://www.gaia-gis.it/fossil/libspatialite/index
While testing my own library under Valgrind I've casually noticed
a very small memory leak caused by the sqlite3_load_extension and
sqlite3_reset_auto_extension logic:
32 bytes in 1 blocks are still reachable in loss record 1 of 1
at 0x4C29DB4: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x696C59F: _dlerror_run (dlerror.c:142)
by 0x696BFC0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
by 0x57C5B26: sqlite3_load_extension (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
by 0x57C5D81: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
by 0x57E58F5: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
by 0x57EB450: sqlite3_step (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
by 0x57EEE4B: sqlite3_exec (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
by 0x4012DE: main (check_extension.c:87)
the check_extension.c basic skeleton is:
char *sql = "SELECT load_extension('libspatialite.so')");
sqlite3_exec (handle, sql, NULL, NULL, &err_msg);
...
sqlite3_reset_auto_extension ();
I've got a quick glance to the sqlite3.c code, and I've noticed that
sqlite3_reset_auto_extension omits at all calling dlclose
once the extension library has been successfully loaded there is no
apparent way allowing to effectively finalize the library handle
before exiting.
absolutely not a big issue; anyway a little bit annoying, because it
tends to pollute Valgrind reports with many "false positive" issues.
best regards,
Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
