RFR 12 : 8072130 : java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX

[Brent Christian]

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 
>>>
>>>
>