[gdal-dev] OSRSetPROJSearchPaths in multithreaded application

[Matthew Amato]

I apologize for resurrecting this thread, but we are running into the same
problem, even after updating the the head of the "release/3.0" branch which
contains Even's fix.

Previously, we would set PROJ_LIB as an environment variable but after
upgrading to 3.x/6.x we now receive thousands of "proj.db not found"
errors. After checking out the above branch, I removed the environment
variable and call OSRSetPROJSearchPaths before calling GDALAllRegister at
the start of my main thread but the problem remains.

What's odd is that it only happens if we use a lot of threads, which makes
me think there may still be a race condition somewhere in GDAL?

If I change my code to be single-threaded, the problem goes away completely.

And advice you could offer would be much appreciated.

Thanks!

On Wed, Jul 17, 2019 at 1:27 PM Dirk Vanden Boer <dirk.vdb at gmail.com> wrote:

>
>
> Op wo 17 jul. 2019 om 17:57 schreef Even Rouault <
> even.rouault at spatialys.com>
>
>> > I did some more investigation, and it seems like the threading is
>> > indeed not the issue.
>> > The issue seems to be that the geotiff library also creates proj
>> > contexts and these contexts do not have
>> > the search paths that are passed to the OSRGetProjTLSContext call.
>>
>> Should be fixed per
>>
>> https://github.com/OSGeo/gdal/commit/48793b5613cf1bf789125516ba845947dc63098f
>> in master
>> and
>>
>> https://github.com/OSGeo/gdal/commit/ffb0ad0c862cf4ef5d6907d1d83cc76fcf8c305b
>> in 3.0 branch
>>
>
> Great, thanks for the quick response and fixes!
>
>>
>> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190731/e9eafbaf/attachment.html>