Re: RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278
On 2/15/18, 12:15 AM, Alan Bateman wrote: On 15/02/2018 07:49, Xueming Shen wrote: Hi, Please help review the change for JDK-819798 issue: https://bugs.openjdk.java.net/browse/JDK-8197988 webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev The change for JDK-8164278 caused a decoding regression. A Tier2 test case, javax/net/ssl/interop/ClientHelloChromeInterOp.java, that uses mime-base64-decoder failed. The "condition" that triggers the decoding to go the fast path is incorrect in the code pushed for JDK-819798. The intent here is to only start/try the fast path when we are at the beginning of a 4-byte legal base64 unit. The correct/appropriate check is to see if shiftto == 18, which means the decoder is still at the beginning of 4-byte unit. ( bits == 0 is a false indicator, as bits might include decoded byte value of 0). The fix is a relatively easy/one line change. This looks okay. Should we create another issue to add more tests in this area to avoid the SSL code finding issues in this area again. Yes, I will do that tomorrow. Just need to get the mach5 going first tonight. thanks, Sherman
Re: RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278
On 15/02/2018 07:49, Xueming Shen wrote: Hi, Please help review the change for JDK-819798 issue: https://bugs.openjdk.java.net/browse/JDK-8197988 webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev The change for JDK-8164278 caused a decoding regression. A Tier2 test case, javax/net/ssl/interop/ClientHelloChromeInterOp.java, that uses mime-base64-decoder failed. The "condition" that triggers the decoding to go the fast path is incorrect in the code pushed for JDK-819798. The intent here is to only start/try the fast path when we are at the beginning of a 4-byte legal base64 unit. The correct/appropriate check is to see if shiftto == 18, which means the decoder is still at the beginning of 4-byte unit. ( bits == 0 is a false indicator, as bits might include decoded byte value of 0). The fix is a relatively easy/one line change. This looks okay. Should we create another issue to add more tests in this area to avoid the SSL code finding issues in this area again. -Alan
RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278
Hi, Please help review the change for JDK-819798 issue: https://bugs.openjdk.java.net/browse/JDK-8197988 webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev The change for JDK-8164278 caused a decoding regression. A Tier2 test case, javax/net/ssl/interop/ClientHelloChromeInterOp.java, that uses mime-base64-decoder failed. The "condition" that triggers the decoding to go the fast path is incorrect in the code pushed for JDK-819798. The intent here is to only start/try the fast path when we are at the beginning of a 4-byte legal base64 unit. The correct/appropriate check is to see if shiftto == 18, which means the decoder is still at the beginning of 4-byte unit. ( bits == 0 is a false indicator, as bits might include decoded byte value of 0). The fix is a relatively easy/one line change. Thanks, Sherman
