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

[Even Rouault]

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.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> 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
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240919/728d20e8/attachment.htm>