RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"
The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" ------------- Commit messages: - Merge branch 'master' into JDK-8273188 - 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Changes: https://git.openjdk.java.net/jdk/pull/5427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273188 Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5427/head:pull/5427 PR: https://git.openjdk.java.net/jdk/pull/5427
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato <naoto@openjdk.org> wrote:
The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265.
On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo().
On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied.
Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8"
Hi Naoto,
The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo().
Doesn't it depend on the OS version and which file system is being used? HFS+ seems to use UTF-16 Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5427
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato <naoto@openjdk.org> wrote:
The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265.
On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo().
On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied.
Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8"
Hi David,
Doesn't it depend on the OS version and which file system is being used? HFS+ seems to use UTF-16
Right. I was not clear enough as to `file system encoding`, what I meant was the `sun.jnu.encoding`, which is always `UTF-8` with this change: https://bugs.openjdk.java.net/browse/JDK-8003228 ------------- PR: https://git.openjdk.java.net/jdk/pull/5427
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato <naoto@openjdk.org> wrote:
The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265.
On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo().
On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied.
Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8"
Hi Naoto, Based on what you've said the core functional change seems okay. Good catch on the uft typo! Pre-existing: The initialization logic in this code is quite odd for the case when no conversion is necessary (we call `utfInitialize` on every call to `convertUtf8ToPlatformString`!), but I assume we do not call `appendBootClassPath` and `appendToClassLoaderSearch` very often? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5427
On Wed, 8 Sep 2021 23:38:38 GMT, David Holmes <dholmes@openjdk.org> wrote:
Pre-existing: The initialization logic in this code is quite odd for the case when no conversion is necessary (we call `utfInitialize` on every call to `convertUtf8ToPlatformString`!), but I assume we do not call `appendBootClassPath` and `appendToClassLoaderSearch` very often?
Indeed. I assume those methods are only used on agent startup. ------------- PR: https://git.openjdk.java.net/jdk/pull/5427
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato <naoto@openjdk.org> wrote:
The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265.
On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo().
On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied.
Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8"
Good sleuthing. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5427
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato <naoto@openjdk.org> wrote:
The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265.
On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo().
On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied.
Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8"
This pull request has now been integrated. Changeset: 54dee132 Author: Naoto Sato <naoto@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/54dee132d1a149165e7478b29b740d086c18... Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5427
participants (3)
-
Alan Bateman
-
David Holmes
-
Naoto Sato