Le 18/09/2024 à 18:27, Fox, Shawn D (US) via gdal-dev a écrit :
Could someone help me understand this sentence from the documentation
at gdal.h: Raster C API — GDAL documentation
<https://gdal.org/en/latest/api/raster_c_api.html> for the GDALDestroy
function?
“Since GDAL 2.4.0, this function may be called by application code,
since it is no longer called automatically, on non-MSVC builds, due to
ordering problems with respect to automatic destruction of global C++
objects.”
What are the ordering problems and why might it be called due to
ordering problems? The statement does state some kind of difference
between MSVC and non-MSVC builds. The sentence doesn’t clearly state
to me whether I should or shouldn’t call that function to cleanup. The
language in the documentation is ambiguous, and it is not clear to me
how important it is to call this method. Cleaning up seems like a
good idea but I could simply free the memory via delete for any object
that is returned instead of calling GDALDestroy.
You don't necessarily have to call GDALDestroy(). It reclaims various
static objects allocated by GDAL. Basically it helps for "valgrind
--leak-check=full" use cases.
The issue that caused it to no longer be registered as a GCC destructor
function is that if you have for example a static GDALDataset object, it
was found that GDALDestroy() was called before the destruction of the
GDALDataset object, which lead to double-free. Cf commit comment of
https://github.com/OSGeo/gdal/commit/e8c9bea5dbe8e90d01d575f94a040fcaee27c24f
On a RHEL8 build, which is non-MSVC, I am observing segmentation
faults. The errors vary from one execution of the program to another.
Hard to tell the reason. Show the code, use Valgrind.
Check also with ldd that your executable isn't linked to 2 different
versions of libproj. The error message you mention is typical of that
situation
--
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
