Skip to content
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

Microsoft STL redistributable found in JDK is out of date #3887

Open
1 task done
AndrewHL76 opened this issue Jul 11, 2024 · 5 comments
Open
1 task done

Microsoft STL redistributable found in JDK is out of date #3887

AndrewHL76 opened this issue Jul 11, 2024 · 5 comments
Labels
bug Issues that are problems in the code as reported by the community testing Issues that enhance or fix our test suites

Comments

@AndrewHL76
Copy link

AndrewHL76 commented Jul 11, 2024

Please provide a brief summary of the bug

It was observed that an outdated version of msvcp140.dll located in the bin folder of installed JDKs. Microsoft published an update in June 2024 and an issue has arisen.

Specifically we have a c++ library being invoked from Java that uses a mutable const mutex that when compiled with the latest Microsoft toolset, crashes due to the mutex now being constructed inappropriately. The issue occurs when an attempt to lock the mutex takes place.

Is it possible to rebuild or repackage with the latest versions of the Microsoft redistributables.

Did you test with the latest update version?

  • Yes

Please provide steps to reproduce where possible

No response

Expected Results

msvcp140.dll is present with a minimum file version of 14.40.33810.0

Actual Results

Current msvcp140.dll version is 14.36.32532.0

What Java Version are you using?

openjdk 21.0.2 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode, sharing)

What is your operating system and platform?

Windows 11

How did you install Java?

msi

Did it work before?

No response

Did you test with other Java versions?

No response

Relevant log output

No response

@AndrewHL76 AndrewHL76 added the bug Issues that are problems in the code as reported by the community label Jul 11, 2024
@karianna karianna transferred this issue from adoptium/adoptium-support Jul 12, 2024
@github-actions github-actions bot added the testing Issues that enhance or fix our test suites label Jul 12, 2024
@sxa
Copy link
Member

sxa commented Jul 15, 2024

Hi @AndrewHL76 - thanks for raising this. I think it's the first time I can recall such a failure reported with the C runtime in all my time with Adoptium/AdoptOpenJDK!

Can you confirm that if you swap in a later one into the JDK directory it works ok, making that a suitable workaround in the meantime?

The tricky thing from our side is that for reproducibility reasons (if you're not aware, Tenurin is 100% binary reproducible) we typically don't always update the compilers to bleeding edge (as building with different versions makes them non reproducible), preferring fixed levels in general, but I appreciate that we may wish to look at an update with this specific failure. Having said that we will not be able to do anything in time for the PSU update this week unfortunately.

@DonOregano
Copy link

I was bitten by this as well. And I put a newer msvcp140.dll into my temurin bin dir, and it works then. Would be awesome to have a fix for this soon-ish :-D
But the workaround works.

@AndrewHL76
Copy link
Author

A swap with newer binaries does indeed work, however this approach is not friendly to our deployment strategy.

@DonOregano Assuming they are your libraries, as an alternative work around you can use the preprocessor definition _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR in your c++ projects that use the mutex class.

Ideally future distributions of JDK have the updated binaries

@DonOregano
Copy link

Oh, thank you! That gives me a way to understand what is really going on here!

@sxa
Copy link
Member

sxa commented Jul 19, 2024

A swap with newer binaries does indeed work, however this approach is not friendly to our deployment strategy.

Yep agree that's far from ideal so will take a look at it options going forward on this one the current release cycle is complete. Thanks to both of you for confirming that we at least have a workaround for anyone else affected by this.

I'll also note for others who may be reading this that it is not specific to the MSI - the .zip downloads of Temurin also contain the runtime dll.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues that are problems in the code as reported by the community testing Issues that enhance or fix our test suites
Projects
Status: Todo
Development

No branches or pull requests

3 participants