On Tue, 10 Dec 2024 23:45:37 GMT, Volodymyr Paprotski <vpaprot...@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