<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.gmailsignatureprefix
{mso-style-name:gmail_signature_prefix;}
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">Just for fun, I changed by code back to cause the crash again. Now it’s difficult to reproduce but here is the part of the callstack showing where the issue occurs. The CPLCleanupTLSList function is the function of interest as it loops
over some type of list. Within a conditional it is adding two numbers together in an array offset and testing a pointer to determine whether to free some memory. This is far down into the weeds of GDAL so I’ve no idea what this function is doing but it’s
above my level of understanding of GDAL internals. We don’t attempt to use any networking capabilities within GDAL as far as I know. When I get it to crash again I’ll step into it some more to see if something jumps out at me.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#0 0x00007fc79b81e241 in unlink_chunk.isra () from /lib64/libc.so.6<o:p></o:p></p>
<p class="MsoNormal">#1 0x00007fc79b81e465 in malloc_consolidate () from /lib64/libc.so.6<o:p></o:p></p>
<p class="MsoNormal">#2 0x00007fc79b81fae0 in _int_free () from /lib64/libc.so.6<o:p></o:p></p>
<p class="MsoNormal">#3 0x00007fc792ab9708 in VSIFree (pData=0x9bfd40) at cpl_vsisimple.cpp:873<o:p></o:p></p>
<p class="MsoNormal">#4 0x00007fc792a78820 in CPLCleanupTLSList (papTLSList=0x7ab950) at cpl_multiproc.cpp:467<o:p></o:p></p>
<p class="MsoNormal">#5 0x00007fc792a799ec in CPLCleanupTLS () at cpl_multiproc.cpp:2247<o:p></o:p></p>
<p class="MsoNormal">#6 0x00007fc79252667c in GDALDriverManager::~GDALDriverManager (this=0x848ae0, __in_chrg=<optimized out>) at gdaldrivermanager.cpp:274<o:p></o:p></p>
<p class="MsoNormal">#7 0x00007fc792526746 in GDALDriverManager::~GDALDriverManager (this=0x848ae0, __in_chrg=<optimized out>) at gdaldrivermanager.cpp:335<o:p></o:p></p>
<p class="MsoNormal">#8 0x00007fc792527989 in GDALDestroyDriverManager () at gdaldrivermanager.cpp:915<o:p></o:p></p>
<p class="MsoNormal">#9 0x00007fc792520fce in GDALDestroy () at gdaldllmain.cpp:86<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</span><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:50 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>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Sep 18, 2024 at 8:32 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>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is not a great plan unless you understand exactly the order of things being destroyed, which is not well-defined between compilation units unless you have done things to guarantee it. It seems likely that GDALDestroy() is attempting
to free things already destroyed during program tear-down. Since your program is exiting, I can't imagine you need to call GDALDestroy() at all. You could also eliminate this issue by instantiating your GDAL class-thingee as the first line of your program
rather than as a static.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><span class="gmailsignatureprefix">-- </span><o:p></o:p></p>
<div>
<p class="MsoNormal">Andrew Bell<br>
<a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>