[9] RFR(S): Crash with assert: symbol conversion failure in java_lang_String::create_from_symbol()

[Coleen Phillimore]

This change is fine because it matches the commented out assert in 
create_from_str().   We should probably figure out what it would take to 
check the characters coming in from JNI and decide whether we should do 
this.  If not, it doesn't make sense to have commented out asserts.   
But this is okay for jdk9.
Thanks,
Coleen


On 9/9/16 8:42 AM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8164561
> http://cr.openjdk.java.net/~thartmann/8164561/webrev.00/
>
> The verification code in java_lang_String::create_from_symbol() that was added by Compact Strings fails because the input symbol does not contain valid UTF8. The problem is that a JCK JNI test passes an invalid UTF8 string as class name to the JNI method "FindClass". In fact, the string contains garbage from reading past array boundaries because of a bug in the test [1]. The JNI spec [2] states that 'name' should be "a fully-qualified class name (that is, a package name, delimited by “/”, followed by the class name). If the name begins with “[“ (the array signature character), it returns an array class. The string is encoded in modified UTF-8".
>
> I nevertheless think that we should not crash in the case of an invalid UTF8 string and therefore disabled the verification code with a comment. We did the same for java_lang_String::create_from_str() [3].
>
> Tested with failing JCK test and JPRT (running).
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JCK-7307244
> [2] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#FindClass
> [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/d060826d0911/src/share/vm/classfile/javaClasses.cpp#l274