If your program uses threads, and you don't make sure to wait for their
termination before calling GDALDestroy, this could explain memory
corruption if they use GDAL TLS, while GDALDestroy() is cleaning the TLS
structures. I'll stop random guessing here.
And you can just get rid of the GDALDestroy() call if it is an
annoyance. It just frees memory, which process termination does anyway.
It is just there so that no still-reachable memory is reported when
running under Valgrind or other similar analyzers.
Le 19/09/2024 à 03:51, Fox, Shawn D (US) via gdal-dev a écrit :
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...@gmail.com>
*Sent:* Wednesday, September 18, 2024 5:50 PM
*To:* Fox, Shawn D (US) <shawn....@baesystems.us>
*Cc:* gdal-dev@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@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...@gmail.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
