Hello,
I was chasing for a long time a small 8 byte memory leak and was able
to identify it in the OGR sqlite extension binding, here's what I
observed:
A call to OGRSQLiteBaseDataSource::OpenOrCreateDB() would invoke
OGR2SQLITE_Register() and then sqlite3_auto_extension(). The latter is
a sqlite3 call that would malloc an 8 byte buffer for the extension
function entry point if the extension is unknown to sqlite3 (was not
previously registered).
This allocation seems to be unmanaged neither by sqlite3 nor by OGR
later causing an 8 byte memory leak. I was able to resolve this by
adding a OGR2SQLITE_UnRegister() stub in ogrsqlitevirtualogr.cpp that
would call in a succession:
>
sqlite3_cancel_auto_extension ((void (*)(void)) OGR2SQLITE_static_register);
sqlite3_reset_auto_extension ();
<
and then have the OGR2SQLITE_UnRegister() stub called in
ogrsqlitedatasource.cpp \ OGRSQLiteBaseDataSource::CloseDB() right
after closing the database:
>
sqlite3_close( hDB );
hDB = nullptr;
OGR2SQLITE_UnRegister();
<
This way the memory leak was gone. My app runs on VS2015/2019 with an
older GDAL release (2.4.4.) so the fix will be a bit different in 3.10
as the HAVE_SQLITE3EXT_H conditionals were not present in 2.4.4..
Best regards,
Deyan
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
