[gdal-dev] Call to GDALDestroy results in occasional core dump, GDAL 3.4.2

[Even Rouault]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240918/7c9aa5aa/attachment.htm>