Hello, it may be needed for sure for the whole session or at least if you need the already registered extension to be available at the next db open attempt.
A deeper look in sqlite3 gave me the sqlite3_shutdown() API that actually frees the extension attached via sqlite3_reset_auto_extension() together with various other sqlite3 stuff. I do not see GDAL to call sqlite3_shutdown() anywhere and I think it is quite reasonable to do it in some GDAL sqlite driver finalization steps - in the OGRSQLiteBaseDataSource destructor, in the Close() method after closing db, etc. Deyan On Thu, Feb 6, 2025 at 12:52 PM Even Rouault <even.roua...@spatialys.com> wrote: > > Deyan > > this sounds more like "still reachable" memory in Valgrind terminology > (https://valgrind.org/docs/manual/faq.html#faq.deflost), that is memory > that is allocated by some component, still reachable by it but never > explicitly freed before the end of the process, and the amount of it > doesn't grow over time. There are certainly many similar such patterns > in GDAL or other libraries it uses, and I don't see that as a bug or > something that requires code changes. > > Even > > Le 06/02/2025 à 11:34, Deyan Vasilev via gdal-dev a écrit : > > 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 > > -- > http://www.spatialys.com > My software is free, but my time generally not. > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
