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
