<p dir="ltr">There are many potential causes. Providing code and a backtrace would allow someone else to look.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2024, 7:28 PM Fox, Shawn D (US) via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="m_-5703378746835040925WordSection1">
<p class="MsoNormal">Could someone help me understand this sentence from the documentation at
<a href="https://gdal.org/en/latest/api/raster_c_api.html" target="_blank" rel="noreferrer">gdal.h: Raster C API — GDAL documentation</a> for the GDALDestroy function?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">“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.”<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.  <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">On a RHEL8 build, which is non-MSVC, I am observing segmentation faults.  The errors vary from one execution of the program to another. 
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Sometimes I observe this error.<u></u><u></u></p>
<p class="MsoNormal">corrupted size vs. prev_size in fastbins<u></u><u></u></p>
<p class="MsoNormal">Aborted (core dumped)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Other times I observe this one<u></u><u></u></p>
<p class="MsoNormal">corrupted double-linked list<u></u><u></u></p>
<p class="MsoNormal">Aborted (core dumped)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Shawn Fox</span><span style="font-size:8.0pt">
</span><span><u></u><u></u></span></p>
</div>
</div>

_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>