Oops! I also meant to take the test off of the ProblemList:
test/jdk/ProblemList.txt
*** 515,526 ****
# jdk_instrument
java/lang/instrument/RedefineBigClass.sh
8065756 generic-all
java/lang/instrument/RetransformBigClass.sh
8065756 generic-all
- java/lang/instrument/BootClassPath/BootClassPathTest.sh
8072130 macosx-all
-
java/lang/management/MemoryMXBean/Pending.java
8158837 generic-all
(Webrev[1] also updated in place)
Thanks,
-Brent
1. http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
On 9/18/18 10:01 AM, Xueming Shen wrote:
+1
On 9/18/18, 9:42 AM, Brent Christian wrote:
Any thoughts on this change? -B
On 9/11/18 3:41 PM, Brent Christian wrote:
Hi,
Please review this change to how the platform encoding is determined
on Mac when loading agents.
Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
Additional details in the bug report:
https://bugs.openjdk.java.net/browse/JDK-8072130
Some background:
Since JDK 8, if MacOS reports an encoding of US-ASCII, but no
encoding hints are provided in environment variables (LANG, LC_ALL,
LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194[1]. (This
allowed apps launched via double-clicked jar to display files
correctly for non-ASCII languages).
A similar encoding tweak was not made in the code path used for
loading agents.
This can come into play when an agent jar includes a Boot-Class-Path
entry containing non-ASCII characters. iconv() gets setup to convert
UTF-8 to US-ASCII[2], but will fail when encountering extended
characters in the entry, so the path in question is not added to the
bootclasspath[3]. This will likely lead to a ClassNotFoundException.
When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run
on a Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a
default encoding of UTF-8 (per 8011194) and creates Agent.jar with
a Boot-Class-Path that includes non-ASCII characters. But the
Boot-Class-Path entry gets skipped when loading Agent.jar, so the
AgentSupport class can't be found.
I propose this be fixed by adding the same UTF-8 encoding adjustment
on MacOS from 8011194 to the agent loading code path.
An additional note:
This bug was challenging to reproduce, in large part because the
8011194 code checks for an absent env var (getenv() == null), but not
for env vars with a blank/empty string value (getenv() == ""), so the
test environment had to be setup in a specific way (e.g. 'unset LANG'
vs 'export LANG=') to reproduce this bug. So I'd like to update the
code to also check for empty string. I also added a couple small
improvements to the test.
Thanks!
-Brent
1. https://bugs.openjdk.java.net/browse/JDK-8011194
2.
http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87
3.
http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873
