[gdal-dev] a possible memory leak in ogr\ogrsf_frmts\sqlite

[Deyan Vasilev]

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.rouault at 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 at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>