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

[Fox, Shawn D (US)]

In our case we have a singleton class that acts as a façade and all of our calls to GDAL Apis are done by the methods of this class.  The rest of our code base only interacts with the singleton so that we only have one project that actually depends directly on the GDAL library.  Since the _instance member is a static smart pointer the destructor of our class and the GDALDestroy function is being called after the main function exits.  So it seems like a similar problem that led to this commit, GDALDestroy(): no longer call it automatically on GCC/CLang (non-MSVC… · OSGeo/gdal at e8c9bea · GitHub<https://github.com/OSGeo/gdal/commit/e8c9bea5dbe8e90d01d575f94a040fcaee27c24f>.  However I’m not really sure why this is a problem because I am not quite clear about what GDAL destroy does.

I’m really looking for more of a clarification of intent.  How is it supposed to be used?  We have numerous programs that use a singleton class in the same way but not all exhibit this problem.  I’m guessing that the only way to be sure that the core dump does not occur is to find a way to explicitly destroy the object before the return statement of the main function so that we can control when GDALDestroy is called.

Shawn Fox

From: Andrew Bell <andrew.bell.ia at gmail.com>
Sent: Wednesday, September 18, 2024 5:01 PM
To: Fox, Shawn D (US) <shawn.fox at baesystems.us>
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Call to GDALDestroy results in occasional core dump, GDAL 3.4.2

External Email Alert
This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


There are many potential causes. Providing code and a backtrace would allow someone else to look.

On Wed, Sep 18, 2024, 7:28 PM Fox, Shawn D (US) via gdal-dev <gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>> wrote:
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
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240919/5fbca350/attachment.htm>