-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
20240610.1.0: still issues related to Visual Studio update with C++ libraries run through Java #10055
Comments
A workaround I found is to remove msvcp140.dll from "C:/hostedtoolcache/windows/Java_Temurin-Hotspot_jdk" with OSGeo/gdal@95d092d |
@rouault - Thank you for bringing this issue to us. We are looking into this issue, we will update you. |
Same issue, even after deployment of runner image version 20240610.1.0 which was supposed to fix the issue: #10020 (comment) |
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. |
Since there is no way to ensure all Java users have JVM installations with the latest vcruntime I plan to define |
I found the answer. Yes it's needed. Longer answer can be found in #10004. |
Instead of removing the older version of the vcruntime from the Temurin JVM installation in the GitHub Actions runner image, define `_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR` when compiling libktx and ${ASTCENC_LIB_TARGET}. This makes the code compatible with older VC runtimes removing the burden from users to ensure their JVM installation uses the latest VC runtime. See actions/runner-images#10055. For further background see actions/runner-images#10004 and https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10669129-N10678728. Includes 2 other minor changes: 1. Move the compiler info dump in `CMakeLists.txt` to before first use of the compiler info and recode it to use `cmake_print_variables`. 2. Disable dump of system and platform info in `tests/loadtests/CMakeLists.txt`.
@rouault - I hope your issue got resolved, as i can see there was a workaround been used - |
@rouault - Closing this issue, thank you for bringing this issue to us. Please feel free to create a new issue if you face any related issues with this windows server 2022 image. |
I'm late to the party, but FYI for people getting here in the future: the problem is not limited to Java programs. I don't use any Java, but because the So if you are installing anything on the Windows runner that has been built against MSVC Redist |
@jackjansen One thing that I do not understand in above posts or posts in other related issues that mention The only case where I can see problems is if an older |
@Sedeniono I think you may be right. In other words: I now think that I my problem was not caused by the incorrect old |
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
Platforms affected
Runner images affected
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
The text was updated successfully, but these errors were encountered: