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@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...@gmail.com> Sent: Wednesday, September 18, 2024 5:01 PM To: Fox, Shawn D (US) <shawn....@baesystems.us> Cc: gdal-dev@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@lists.osgeo.org<mailto:gdal-dev@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@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
