20240610.1.0: still issues related to Visual Studio update with C++ libraries run through Java

[rouault]

Description

GDAL has been affected by #10004 with the issue with std::mutex and the 20240603 image update. Since 20240610 has been released, I've retried re-enabling GDAL Windows CI testing, and they mostly work, except Java related tests, that run my C++ library through JNI. I suspect the JVM shipped in the image uses a too old VC redist

Cf https://github.com/OSGeo/gdal/actions/runs/9487561784/job/26144477503?pr=10198 for a faulty run

The following tests FAILED:
	  1 - java_GDALOverviews (Failed)
	  2 - java_gdalinfo (Failed)
	  3 - java_ogr2ogr_1 (Failed)
	  4 - java_ogrinfo_1 (Failed)
	  5 - java_ogrinfo_2 (Failed)
	  6 - java_ogr2ogr_2 (Failed)
	  7 - java_ogr2ogr_3 (Failed)
	  8 - java_ogrinfo_3 (Failed)
	  9 - java_OSRTransform (Failed)
	 10 - java_gdalmajorobject (Failed)
	 11 - java_GDALTestIO (Failed)
	 12 - java_GDALTestMultiDim (SEGFAULT)
	 13 - java_GDALContour (Failed)
	 15 - java_ogrtindex (Failed)
	 16 - java_OSRTest (Failed)

 9: #
9: # A fatal error has been detected by the Java Runtime Environment:
9: #
9: #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd926192a0, pid=3372, tid=0x0000000000001464
9: #
9: # JRE version: OpenJDK Runtime Environment (8.0_412-b08) (build 1.8.0_412-b08)
9: # Java VM: OpenJDK 64-Bit Server VM (25.412-b08 mixed mode windows-amd64 compressed oops)
9: # Problematic frame:
9: # C  [msvcp140.dll+0x192a0]
9: #
9: # Core dump written. Default location: D:\a\gdal\gdal\build\swig\java\hs_err_pid3372.mdmp
9: #
9: # An error report file with more information is saved as:
9: # D:\a\gdal\gdal\build\swig\java\hs_err_pid3372.log

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

Runner Image
Image: windows-2022
Version: 20240610.1.0

Is it regression?

Last good build: https://github.com/OSGeo/gdal/actions/runs/9392254916/job/25869181603?pr=10145 (Version: 20240514.3.0)

Expected behavior

should segfault

Actual behavior

segfaults

Repro steps

Build a C++ library using std::mutex with a JNI interface, and run it with the JVM provided in the image

[rouault]

A workaround I found is to remove msvcp140.dll from "C:/hostedtoolcache/windows/Java_Temurin-Hotspot_jdk" with OSGeo/gdal@95d092d

[ijunaidm]

@rouault - Thank you for bringing this issue to us. We are looking into this issue, we will update you.

[danielhjacobs]

Perhaps related: https://github.com/ruffle-rs/ruffle/actions/runs/9501856001/job/26188442117?pr=13346

code 0xc0000005: Invalid access to memory location. (os error 998)

Seems similar to:

EXCEPTION_ACCESS_VIOLATION (0xc0000005)

[lelegard]

Same issue, even after deployment of runner image version 20240610.1.0 which was supposed to fix the issue: #10020 (comment)

[BrianMouncer]

Even assuming the image get fixed to update all the runtime dlls that are shippen by every application and version of java on the agent, that just means we will build and ship java sdks that will blow up in a similarly spectacular and hard to diagnose way on customers machines who have default unmodified versions of java installed on their machines.

This does not seem like a good compatibility experience for our customers.
Would it be better to revert back to the previous version of visual studio?

[MarkCallow]

A workaround I found is to remove msvcp140.dll from "C:/hostedtoolcache/windows/Java_Temurin-Hotspot_jdk" with OSGeo/gdal@95d092d

Since there is no way to ensure all Java users have JVM installations with the latest vcruntime I plan to define _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR instead when building our JNI modules and dependencies. Is this define needed with clangcl as well as msvc?

[MarkCallow]

Is this define needed with clangcl as well as msvc?

I found the answer. Yes it's needed. Longer answer can be found in #10004.