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

[Andrew Bell]

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