[gdal-dev] four threads are huh, five are buh? Regressions w/ GDAL 3.5.2/PROJ_9.1.0

[Christian Brock]

I have some special issue and would be glad for suggestions.

We run complex regression tests using environmental files -- too complex for a bug report ;-(

Moving from GDAL_2.4.2/PROJ_5.2.0 to GDAL 3.5.2/PROJ_9.1.0 we run into regressions.

The most stunning observation is that the issue only occurs when USING MORE THAN FOUR THREADS!
Can anyone think of something that is true with five or more threads but not below?

Besides this I should mention, that we use Java bindings

The issue is
- file format independent,
- were observed on ubuntu 20.04 and 22.04,
- affects a sample with the following coordinate system:
PROJCS["Transverse Mercator",GEOGCS["Potsdam_IST_V2_0",DATUM["Potsdam_IST_V2_0",SPHEROID["Bessel",6377397.155,299.152813106079],TOWGS84[583,68,399.5,0,0,1.36E-05,1.13E-05]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",1],PARAMETER["false_easting",3500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH]]"
- WGS84 and all UTM systems are good.

I should also mention, that this issue affects only the second sample, when I run more than one sample with the PROJCS above.
When I change the sample order, it is the second sample again!

And as a final point, there are random memory corruptions every couple of hours.

So again, please step forward when you know of anything inside GDAL, PROJ or Java bindings that cares about the number of threads.

Many thanks
--Chr.



This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service <https://www.amdocs.com/about/email-terms-of-service>