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

[Fox, Shawn D (US)]

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.

#0  0x00007fc79b81e241 in unlink_chunk.isra () from /lib64/libc.so.6
#1  0x00007fc79b81e465 in malloc_consolidate () from /lib64/libc.so.6
#2  0x00007fc79b81fae0 in _int_free () from /lib64/libc.so.6
#3  0x00007fc792ab9708 in VSIFree (pData=0x9bfd40) at cpl_vsisimple.cpp:873
#4  0x00007fc792a78820 in CPLCleanupTLSList (papTLSList=0x7ab950) at cpl_multiproc.cpp:467
#5  0x00007fc792a799ec in CPLCleanupTLS () at cpl_multiproc.cpp:2247
#6  0x00007fc79252667c in GDALDriverManager::~GDALDriverManager (this=0x848ae0, __in_chrg=<optimized out>) at gdaldrivermanager.cpp:274
#7  0x00007fc792526746 in GDALDriverManager::~GDALDriverManager (this=0x848ae0, __in_chrg=<optimized out>) at gdaldrivermanager.cpp:335
#8  0x00007fc792527989 in GDALDestroyDriverManager () at gdaldrivermanager.cpp:915
#9  0x00007fc792520fce in GDALDestroy () at gdaldllmain.cpp:86

Shawn Fox
From: Andrew Bell <andrew.bell.ia at gmail.com>
Sent: Wednesday, September 18, 2024 5:50 PM
To: Fox, Shawn D (US) <shawn.fox at baesystems.us>
Cc: gdal-dev at 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.



On Wed, Sep 18, 2024 at 8:32 PM Fox, Shawn D (US) via gdal-dev <gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>> wrote:
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.

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.

--
Andrew Bell
andrew.bell.ia at gmail.com<mailto:andrew.bell.ia at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240919/be88a767/attachment.htm>