<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Lucida Sans Unicode";
panose-1:2 11 6 2 3 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">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,
<a href="https://github.com/OSGeo/gdal/commit/e8c9bea5dbe8e90d01d575f94a040fcaee27c24f">
GDALDestroy(): no longer call it automatically on GCC/CLang (non-MSVC… · OSGeo/gdal@e8c9bea · GitHub</a>. However I’m not really sure why this is a problem because I am not quite clear about what GDAL destroy does.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Shawn Fox<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Andrew Bell <andrew.bell.ia@gmail.com> <br>
<b>Sent:</b> Wednesday, September 18, 2024 5:01 PM<br>
<b>To:</b> Fox, Shawn D (US) <shawn.fox@baesystems.us><br>
<b>Cc:</b> gdal-dev@lists.osgeo.org<br>
<b>Subject:</b> Re: [gdal-dev] Call to GDALDestroy results in occasional core dump, GDAL 3.4.2<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<table class="MsoNormalTable" border="1" cellspacing="0" cellpadding="0" width="97%" style="width:97.0%;margin-left:5.4pt;border-collapse:collapse;border:none">
<tbody>
<tr style="height:21.2pt">
<td width="97%" valign="top" style="width:97.0%;border:solid red 1.0pt;padding:0in 5.4pt 0in 5.4pt;height:21.2pt">
<p class="MsoNormal" align="center" style="mso-margin-top-alt:auto;margin-bottom:4.0pt;text-align:center;background:white">
<strong><u><span style="font-size:13.5pt;font-family:"Calibri",sans-serif;color:red">External Email Alert</span></u></strong><o:p></o:p></p>
</td>
</tr>
<tr style="height:21.2pt">
<td width="1440" valign="top" style="width:15.0in;border:solid red 1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt;height:21.2pt">
<p class="MsoNormal" align="center" style="mso-margin-top-alt:3.0pt;margin-right:0in;margin-bottom:4.0pt;margin-left:0in;text-align:center;background:white">
<strong><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:black">This email has been sent from an account outside of the BAE Systems network.</span></strong><o:p></o:p></p>
<p class="MsoNormal" align="center" style="mso-margin-top-alt:auto;margin-bottom:4.0pt;text-align:center">
<span style="font-size:7.5pt">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.</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><o:p> </o:p></p>
<p>There are many potential causes. Providing code and a backtrace would allow someone else to look.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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">gdal.h: Raster C API — GDAL documentation</a> for the GDALDestroy function?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">“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.”<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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. <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On a RHEL8 build, which is non-MSVC, I am observing segmentation faults. The errors vary from one execution of the program to another.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Sometimes I observe this error.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">corrupted size vs. prev_size in fastbins<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Aborted (core dumped)<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Other times I observe this one<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">corrupted double-linked list<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Aborted (core dumped)<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>