RFR: JDK-8244703: "platform encoding not initialized" exceptions with debugger, JNI

Alex Menkov alexey.menkov at oracle.com
Sat May 23 00:15:28 UTC 2020


Hi Serguei,

thanks for the review.

On 05/22/2020 12:47, serguei.spitsyn at oracle.com wrote:
> Hi Alex,
> 
> The fix looks good.
> 
>  > And I'm not sure why len+len/2+2 is used there.
>  > In my fix I allocated len*4+1 (for the worst case - each symbol 
> requires 4 bytes to encode plus 1 byte for terminal 0).
> 
> I agree, the size len+len/2+2 looks very strange.
> Most likely, we get error messages truncated.

I suppose usually system error messages are in English (i.e. each symbol 
requires only 1 byte in utf8), so no truncation occurs.

> Should we replace it with len * sizeof(int) + 1 ?

size of utf8 string does not depend on sizeof(int).
Per RFC each symbol can be encoded by 1..4 byte(s).

Maybe Alan can explain this len+len/2+2 value.

--alex

> 
> Thanks,
> Serguei
> 
> On 5/22/20 11:33, Alex Menkov wrote:
>> Hi Alan,
>>
>> thank you for the review.
>>
>> On 05/22/2020 11:16, Alan Bateman wrote:
>>> On 22/05/2020 18:50, Alex Menkov wrote:
>>>> Hi all,
>>>>
>>>> please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8244703
>>>> webrev:
>>>> http://cr.openjdk.java.net/~amenkov/jdk15/jdwp_javalib_dep/webrev/
>>>>
>>>> The issue is a regression from JDK-8222529 which introduced 
>>>> dependency jdwp lib of java lib.
>>>> The fix removes the dependency and implements platform to utf8 
>>>> conversion using existing jdwp code.
>>> This looks good to me. While we are in the area, can you look at 
>>> printLastError in transport.c? I'm just wondering if parentheses 
>>> could be added to "len+len/2+2" to make it clear how maxlen is set.
>>
>> Not sure I understand what parentheses do you mean.
>>
>> And I'm not sure why len+len/2+2 is used there.
>> In my fix I allocated len*4+1 (for the worst case - each symbol 
>> requires 4 bytes to encode plus 1 byte for terminal 0).
>>
>> --alex
>>
>>>
>>> -Alan.
>>>
>>>
> 


More information about the serviceability-dev mailing list