RFR: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni

[Volodymyr Paprotski]

On Tue, 10 Dec 2024 23:45:37 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> @TobiHartmann  There are still some unanswered questions I have, but committing this since we need to work around vacation schedules.
> 
> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This fix fixes the crash but I don't understand entirely why the crash happens in the first place.
> 
> The issue fixed here are all the CheckJNI warnings:
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> Crash has nothing to do with String.indexOf work, but was introduced by my `8319429: Resetting MXCSR flags degrades ecore` change. I was able to get HelloWorld to crash on Windows (`-Xcheck:jni -XX:+EnableX86ECoreOpts`). Same command on linux produces hundreds of CheckJNI warnings. Is it odd that its only being found now, no other CheckJNI tests?
> 
> I would appreciate some help/reviews from somebody more aware of the Java-to-C linkage. I think I got the masks fixed, but there is one specific place (see the 'FIXME' question in the diff) for Windows I am not certain about. (@sviswa7 is on vacation for few more weeks)
> 
> Note: Crash on windows (if I have the Windows debugger actually correct), happens on:
> 
> 0x000001f2525f13c1:   fxrstor64 (%rsp)
> Stack:
> 0x00000088f1bfe060:   00007ff8b4384310 0000025bfaeb2200
> 
> 
> `00007ff8` _seems_ like a valid mxcsr value, only way it should crash is if top 2 bytes weren't zeroes, which they are.

(back from vacation. After discussing this with Sandhya, will have an update soon)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2578090185