RFR(S): 8145015: jni_GetStringCritical asserts for empty strings

Tobias Hartmann tobias.hartmann at oracle.com
Mon Dec 14 07:11:51 UTC 2015


Hi Volker,

thanks for taking care of this! Your fix looks good to me (not a reviewer).

Best,
Tobias

On 09.12.2015 18:53, Volker Simonis wrote:
> Hi,
> 
> can somebody please review and sponsor the following fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/
> https://bugs.openjdk.java.net/browse/JDK-8145015
> 
> The problem is that change "8141132: JEP 254: Compact Strings" removed
> the handling for empty strings from jni_GetStringCritical(). As a
> consequence, the functions will now assert with:
> 
> assert(is_within_bounds(which)) failed: index 0 out of bounds 0
> 
> if called with a string of length zero (because it tries to access the
> zeroth element of a zero-length array).
> 
> The fix is trivial, just use 's_value->base(T_CHAR)' instead of
> 's_value->char_at_addr(0)'.
> 
> While doing this fix I also noticed that jni_GetStringCritical()
> doesn't handle out-of-memory situations when creating a new character
> array (before this wasn't necessary because it always returned the
> original character array, but now with compressed strings it may have
> to allocate a new array). So I've also added the new check by using
> NEW_C_HEAP_ARRAY_RETURN_NULL() instead of NEW_C_HEAP_ARRAY().
> 
> Notice that I also allocate one extra character for zero termination.
> While it seems that this is not strictly necessary, it is now the same
> code like in jni_GetStringChars(). And it again simplifies the
> handling of zero-length strings. Without the extra character it would
> be hard to distinguish out-of-memory errors from the allocation of
> zero bytes, because malloc() is free to return NULL if called with an
> allocation size of zero.
> 
> Thank you and best regards,
> Volker
> 


More information about the hotspot-dev mailing list