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

[Fox, Shawn D (US)]

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.

On a RHEL8 build, which is non-MSVC, I am observing segmentation faults.  The errors vary from one execution of the program to another.

Sometimes I observe this error.
corrupted size vs. prev_size in fastbins
Aborted (core dumped)

Other times I observe this one
corrupted double-linked list
Aborted (core dumped)

Our code is not very complex.  It calls GDALRegister in the main thread at the beginning, we perform some CRS transformations during the lifetime of the program, and GDALDestroy from the main thread before exiting.  I do not observe problems with an MSVC build using Visual Studio 2019. If others using GDAL 2.4.x or later on Linux systems could share with me how you handle shutdown and cleanup, I'd appreciate it.

Thanks,
Shawn Fox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240918/26fffe4e/attachment.htm>