From hedongbo at huawei.com Tue Jun 1 06:15:21 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Tue, 1 Jun 2021 14:15:21 +0800 Subject: [8u] RFR 8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: References: Message-ID: <9edf1421-49e7-9c3c-870a-fe04dfecebf5@huawei.com> ping? On 5/21/2021 2:36 PM, He Dongbo(JVM) wrote: > Hi, > > Original Bug: > ???? https://bugs.openjdk.java.net/browse/JDK-8207160 > ???? http://hg.openjdk.java.net/jdk/jdk/rev/e3411e5e473d > > Patch does not apply to 8u cleanly, because the class version in the test is 52, not 55. > 8u webrev: http://cr.openjdk.java.net/~dongbohe/8207160/webrev.00 > > Tested with tier1. No regression in tests. > > The test in the patch passes in 8u, but but our customers reproduced this problem on 8u. The error is as follows: > ```java > [INFO] Compiling 347 source files to /opt/build/TransE2EFrontendService/service/nmltrans_common/../../target/classes/nmltrans_common > An exception has occurred in the compiler (1.8.0_242). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. > java.lang.NullPointerException > ??????? at com.sun.tools.javac.jvm.Code.width(Code.java:279) > ??????? at com.sun.tools.javac.jvm.ClassReader.initParameterNames(ClassReader.java:2082) > ??????? at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2040) > ??????? at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2252) > ??????? at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2324) > ??????? at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2511) > ??????? at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2442) > ??????? at com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) > ??????? at com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:240) > ??????? at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574) > ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037) > ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:973) > ??????? at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:369) > ??????? at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:365) > ??????? at com.sun.tools.javac.comp.Resolve.findImmediateMemberType(Resolve.java:1935) > ??????? at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:1990) > ??????? at com.sun.tools.javac.comp.Resolve.findIdentInType(Resolve.java:2174) > ??????? at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3412) > ??????? at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3278) > ??????? at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897) > ??????? at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576) > ??????? at com.sun.tools.javac.comp.Attr.attribType(Attr.java:638) > ??????? at com.sun.tools.javac.comp.Attr.attribType(Attr.java:631) > ??????? at com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:834) > ??????? at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:558) > ??????? at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) > ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437) > ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:449) > ??????? at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:528) > ??????? at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) > ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437) > ??????? at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) > ??????? at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574) > ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037) > ??????? at com.sun.tools.javac.comp.Enter.complete(Enter.java:493) > ??????? at com.sun.tools.javac.comp.Enter.main(Enter.java:471) > ??????? at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:982) > ??????? at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) > ??????? at com.sun.tools.javac.main.Main.compile(Main.java:523) > ??????? at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129) > ??????? at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138) > ??????? at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) > ??????? at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174) > ??????? at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1075) > ??????? at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168) > ??????? at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) > ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) > ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) > ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > ??????? at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > ??????? at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) > ??????? at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) > ??????? at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > ??????? at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) > ??????? at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) > ??????? at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) > ??????? at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) > ??????? at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) > ??????? at org.apache.maven.cli.MavenCli.main(MavenCli.java:193) > ??????? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ??????? at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ??????? at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ??????? at java.lang.reflect.Method.invoke(Method.java:498) > ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282) > ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225) > ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406) > ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347) > ``` > -- thanks, hedongbo From zgu at redhat.com Tue Jun 1 14:13:26 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Jun 2021 10:13:26 -0400 Subject: [8u] RFR 8027154: [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails In-Reply-To: <4CBF906A-AAB4-4A57-8396-DF206CCDFBFA@amazon.com> References: <4CBF906A-AAB4-4A57-8396-DF206CCDFBFA@amazon.com> Message-ID: <40593c8b-2482-3804-733a-f62c3974a020@redhat.com> Thanks, Paul. Tagged for approval. -Zhengyu On 5/28/21 2:36 PM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Thursday, May 20, 2021 at 12:07 PM > To: jdk8u-dev > Subject: [8u] RFR 8027154: [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails > > I would like to backport this patch to 8u for parity with Oracle 8u301. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8027154 > patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/59b6ea076972 > > > The original patch does not apply cleanly, but only conflict is @bug > line, due to 8u does not "@key headful" line above (JDK-8160974, still > not yet pushed) > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8027154-8u/webrev.00/ > > Test: > The test passed on Linux x86_64 > > Thanks, > > -Zhengyu > > From sgehwolf at redhat.com Tue Jun 1 15:04:11 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Jun 2021 17:04:11 +0200 Subject: [8u] RFR: 8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address Message-ID: Hi, Please review this test fix backport for OpenJDK 8u. The patch didn't apply cleanly. Differences are in copyright header and test tags due to different context. Otherwise the patch is the same. Bug: https://bugs.openjdk.java.net/browse/JDK-8134989 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134989/jdk8/01/webrev/ Testing: updated test passes. Thoughts? Thanks, Severin From zgu at redhat.com Tue Jun 1 15:46:19 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Jun 2021 11:46:19 -0400 Subject: [8u] RFR: 8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address In-Reply-To: References: Message-ID: Looks good. -Zhengyu On 6/1/21 11:04 AM, Severin Gehwolf wrote: > Hi, > > Please review this test fix backport for OpenJDK 8u. The patch didn't > apply cleanly. Differences are in copyright header and test tags due to > different context. Otherwise the patch is the same. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134989 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134989/jdk8/01/webrev/ > > Testing: updated test passes. > > Thoughts? > > Thanks, > Severin > From sgehwolf at redhat.com Tue Jun 1 16:00:44 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Jun 2021 18:00:44 +0200 Subject: [8u] RFR: 8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address In-Reply-To: References: Message-ID: <6296190228edfed12c7f5aef87edabf9bc6fac77.camel@redhat.com> On Tue, 2021-06-01 at 11:46 -0400, Zhengyu Gu wrote: > Looks good. Thanks for the review! Cheers, Severin From hohensee at amazon.com Tue Jun 1 16:54:12 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 1 Jun 2021 16:54:12 +0000 Subject: [8u] RFR: 8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Severin Gehwolf Date: Tuesday, June 1, 2021 at 8:05 AM To: jdk8u-dev Subject: [8u] RFR: 8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address Hi, Please review this test fix backport for OpenJDK 8u. The patch didn't apply cleanly. Differences are in copyright header and test tags due to different context. Otherwise the patch is the same. Bug: https://bugs.openjdk.java.net/browse/JDK-8134989 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134989/jdk8/01/webrev/ Testing: updated test passes. Thoughts? Thanks, Severin From zgu at redhat.com Tue Jun 1 19:07:54 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Jun 2021 15:07:54 -0400 Subject: [8u] RFR 8196181: sun/java2d/GdiRendering/InsetClipping.java fails Message-ID: I would like to backport this patch to 8u for parity with Oracle 8u311. The original bug: https://bugs.openjdk.java.net/browse/JDK-8196181 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/0ad172f3edb3 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8196181-8u/webrev.00/ The original patch does not apply cleanly. 1) The test is not in 8u's ProblemList.txt 2) Copyright line conflicts in the test file. Test: Updated test passed on Windows 10 and Linux x86_64 Thanks, -Zhengyu From volker.simonis at gmail.com Tue Jun 1 19:36:53 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 1 Jun 2021 21:36:53 +0200 Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr Message-ID: Hi, can I please get a review for this backport? This change initially went into jdk 13 and has already been downported to jdk 11u more than a year ago. But as jdk8u is still used a lot and increasingly in containerized environments I think it still makes a lot of sense to downport it to jdk 8u as well. If the JVM crashes in a containerized environment with its ephemeral file system it becomes impossible to do any post mortem analysis of the problem. In such situations the ability to dump the hs_err file to stdout/stderr is very useful, because many container environments log the stdout/stderr stream by default. Original issue: https://bugs.openjdk.java.net/browse/JDK-8220786 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8220787 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695 jdk11 backport: https://bugs.openjdk.java.net/browse/JDK-8238531 jdk11 CSR: https://bugs.openjdk.java.net/browse/JDK-8238532 jdk11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/783a56f3ac1f jdk8 backport: https://bugs.openjdk.java.net/browse/JDK-8268055 jdk8 CSR: https://bugs.openjdk.java.net/browse/JDK-8268058 jdk8 webrev: http://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/ I had to do quite some, but trivial changes to the jdk 11 backport (which I started with) to fit it into jdk 8u: arguments.cpp ------------------- In jdk 11 "FLAG_SET_CMDLINE(boolean, ...)" expands to "JVMFlag::Error boolAtPut(JVMFlagsWithType flag, bool value, JVMFlag::Flags origin)" which returns a "JVMFlag::Error" and can be checked for success. In jdk 8, "FLAG_SET_CMDLINE(boolean, ...)" expands to "void boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags origin)" which returns void, so there's nothing to check for... vmError.cpp ---------------- I think the initial implementation has a bug in the following code: - if (fd_log != -1) { + if (fd_log > 3) { close(fd_log); I think the intention is to close the log stream if it was not stdout (i.e. "1") or stderr (i.e. "2") but it checks for "fd_log > 3". I've fixed this in the downport but I'm happy to revert the fix if somebody has a good explanation for the original code: - if (log.fd() != defaultStream::output_fd()) { + if (log.fd() > 2) { ErrorFileRedirectTest.java --------------------------------- - path/package shuffling for the test library - use "Platform.isDebugBuild()" instead of "@requires (vm.debug == true)" which is not supported in jdk8 - remove "-XX:-CreateCoredumpOnCrash" option because it doesn't exist in jdk 8 - use "-XX:ErrorHandlerTest=12" instead of "-XX:ErrorHandlerTest=14" because "14" is not available in jdk 8. But "12" still generates a SIGSEV by reading from memory address 0. - check for "T H R E A D" in the output because jdk 8 has no "S U M M A R Y" section. The jdk 8 CSR (https://bugs.openjdk.java.net/browse/JDK-8268058) has been reviewed and waits for approval. Thank you and best regards, Volker From hohensee at amazon.com Tue Jun 1 23:17:49 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 1 Jun 2021 23:17:49 +0000 Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr Message-ID: <537B865D-823E-4FC2-8FED-90EE8B0D403E@amazon.com> Also looks to me like the test in vmError.cpp should be "> 2" rather than "> 3". The original review thread https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-March/033293.html has no discussion of why it's 3 instead of 2, but, since "> 3" is in tip, I'd rather keep "> 3" in this backport, fix it in tip, then backport the fix to 11u and 8u. It needs to be fixed in tip and 11u anyway, and doing it the formal way will keep things organized. Otherwise lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Volker Simonis Date: Tuesday, June 1, 2021 at 12:37 PM To: jdk8u-dev Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr Hi, can I please get a review for this backport? This change initially went into jdk 13 and has already been downported to jdk 11u more than a year ago. But as jdk8u is still used a lot and increasingly in containerized environments I think it still makes a lot of sense to downport it to jdk 8u as well. If the JVM crashes in a containerized environment with its ephemeral file system it becomes impossible to do any post mortem analysis of the problem. In such situations the ability to dump the hs_err file to stdout/stderr is very useful, because many container environments log the stdout/stderr stream by default. Original issue: https://bugs.openjdk.java.net/browse/JDK-8220786 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8220787 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695 jdk11 backport: https://bugs.openjdk.java.net/browse/JDK-8238531 jdk11 CSR: https://bugs.openjdk.java.net/browse/JDK-8238532 jdk11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/783a56f3ac1f jdk8 backport: https://bugs.openjdk.java.net/browse/JDK-8268055 jdk8 CSR: https://bugs.openjdk.java.net/browse/JDK-8268058 jdk8 webrev: http://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/ I had to do quite some, but trivial changes to the jdk 11 backport (which I started with) to fit it into jdk 8u: arguments.cpp ------------------- In jdk 11 "FLAG_SET_CMDLINE(boolean, ...)" expands to "JVMFlag::Error boolAtPut(JVMFlagsWithType flag, bool value, JVMFlag::Flags origin)" which returns a "JVMFlag::Error" and can be checked for success. In jdk 8, "FLAG_SET_CMDLINE(boolean, ...)" expands to "void boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags origin)" which returns void, so there's nothing to check for... vmError.cpp ---------------- I think the initial implementation has a bug in the following code: - if (fd_log != -1) { + if (fd_log > 3) { close(fd_log); I think the intention is to close the log stream if it was not stdout (i.e. "1") or stderr (i.e. "2") but it checks for "fd_log > 3". I've fixed this in the downport but I'm happy to revert the fix if somebody has a good explanation for the original code: - if (log.fd() != defaultStream::output_fd()) { + if (log.fd() > 2) { ErrorFileRedirectTest.java --------------------------------- - path/package shuffling for the test library - use "Platform.isDebugBuild()" instead of "@requires (vm.debug == true)" which is not supported in jdk8 - remove "-XX:-CreateCoredumpOnCrash" option because it doesn't exist in jdk 8 - use "-XX:ErrorHandlerTest=12" instead of "-XX:ErrorHandlerTest=14" because "14" is not available in jdk 8. But "12" still generates a SIGSEV by reading from memory address 0. - check for "T H R E A D" in the output because jdk 8 has no "S U M M A R Y" section. The jdk 8 CSR (https://bugs.openjdk.java.net/browse/JDK-8268058) has been reviewed and waits for approval. Thank you and best regards, Volker From hohensee at amazon.com Tue Jun 1 23:22:08 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 1 Jun 2021 23:22:08 +0000 Subject: [8u] RFR 8196181: sun/java2d/GdiRendering/InsetClipping.java fails Message-ID: <379E7128-F727-498B-81E5-26661EF261A2@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Zhengyu Gu Date: Tuesday, June 1, 2021 at 12:08 PM To: jdk8u-dev Subject: [8u] RFR 8196181: sun/java2d/GdiRendering/InsetClipping.java fails I would like to backport this patch to 8u for parity with Oracle 8u311. The original bug: https://bugs.openjdk.java.net/browse/JDK-8196181 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/0ad172f3edb3 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8196181-8u/webrev.00/ The original patch does not apply cleanly. 1) The test is not in 8u's ProblemList.txt 2) Copyright line conflicts in the test file. Test: Updated test passed on Windows 10 and Linux x86_64 Thanks, -Zhengyu From gnu.andrew at redhat.com Wed Jun 2 04:53:53 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Jun 2021 05:53:53 +0100 Subject: [IMPORTANT] 8u & 8u-dev now CLOSED FOR PUSHES for rampdown of 8u302 Message-ID: <20210602045353.GA2067111@rincewind> Hi all, We are now ramping down for the release of OpenJDK 8u302 in July. I have tagged 8u-dev locally and will promote b05 once build testing is complete. jdk8u/jdk8u will be closed until this promotion is completed. After that, requests for regression fixes for 8u302 can be made using the jdk8u-critical-request label. jdk8u/jdk8u-dev will be closed until hgupdater is switched over to use openjdk8u312. Please await further e-mail before pushing changes. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Wed Jun 2 10:16:39 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 Jun 2021 12:16:39 +0200 Subject: [8u] RFR (S) 8065215: Print warning summary at end of configure In-Reply-To: <43a6cc4b-a735-8d1f-45d2-714c9ed64145@redhat.com> References: <43a6cc4b-a735-8d1f-45d2-714c9ed64145@redhat.com> Message-ID: <28e5b5f357d31186b87dbb174b48072d2b4c9280.camel@redhat.com> Hi Aleksey, On Tue, 2021-04-27 at 11:52 +0200, Aleksey Shipilev wrote: > Original RFE: > ?? https://bugs.openjdk.java.net/browse/JDK-8065215 > ?? https://hg.openjdk.java.net/jdk9/jdk9/rev/eefa97d0d263 > > I would like to backport this 8u build system change to improve error > detection during configure. > This also allows cleaner backport of JDK-8079891. > > The patch has a few minor differences: > ?? *) There is no CUSTOM_SUMMARY_AND_WARNINGS_HOOK, no configure.ac > hunk does not apply automatically; > ?? *) There are no relevant "has been successfully created" blocks in > help.m4; > ?? *) generated-configure.sh is obviously different; > > 8u webrev: > ?? https://cr.openjdk.java.net/~shade/8065215/webrev.8u.01/ > > Testing: 8u build; injecting synthetic AS_MSG_WARN into .m4 files > shows the warning at the end of > configure This looks fine. Please be sure to freshly generate generated- configure.sh before you push (after approval of course). Thanks, Severin From volker.simonis at gmail.com Wed Jun 2 11:01:17 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Jun 2021 13:01:17 +0200 Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr In-Reply-To: <537B865D-823E-4FC2-8FED-90EE8B0D403E@amazon.com> References: <537B865D-823E-4FC2-8FED-90EE8B0D403E@amazon.com> Message-ID: OK, I've reverted my fix in vmError.cpp as suggested. Thanks for reviewing, Volker On Wed, Jun 2, 2021 at 1:17 AM Hohensee, Paul wrote: > > Also looks to me like the test in vmError.cpp should be "> 2" rather than "> 3". The original review thread > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-March/033293.html > > has no discussion of why it's 3 instead of 2, but, since "> 3" is in tip, I'd rather keep "> 3" in this backport, fix it in tip, then backport the fix to 11u and 8u. It needs to be fixed in tip and 11u anyway, and doing it the formal way will keep things organized. > > Otherwise lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Volker Simonis > Date: Tuesday, June 1, 2021 at 12:37 PM > To: jdk8u-dev > Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr > > Hi, > > can I please get a review for this backport? > > This change initially went into jdk 13 and has already been downported > to jdk 11u more than a year ago. But as jdk8u is still used a lot and > increasingly in containerized environments I think it still makes a > lot of sense to downport it to jdk 8u as well. > > If the JVM crashes in a containerized environment with its ephemeral > file system it becomes impossible to do any post mortem analysis of > the problem. In such situations the ability to dump the hs_err file to > stdout/stderr is very useful, because many container environments log > the stdout/stderr stream by default. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8220786 > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8220787 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695 > > jdk11 backport: https://bugs.openjdk.java.net/browse/JDK-8238531 > jdk11 CSR: https://bugs.openjdk.java.net/browse/JDK-8238532 > jdk11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/783a56f3ac1f > > jdk8 backport: https://bugs.openjdk.java.net/browse/JDK-8268055 > jdk8 CSR: https://bugs.openjdk.java.net/browse/JDK-8268058 > jdk8 webrev: http://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/ > > I had to do quite some, but trivial changes to the jdk 11 backport > (which I started with) to fit it into jdk 8u: > > arguments.cpp > ------------------- > In jdk 11 "FLAG_SET_CMDLINE(boolean, ...)" expands to "JVMFlag::Error > boolAtPut(JVMFlagsWithType flag, bool value, JVMFlag::Flags origin)" > which returns a "JVMFlag::Error" and can be checked for success. In > jdk 8, "FLAG_SET_CMDLINE(boolean, ...)" expands to "void > boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags > origin)" which returns void, so there's nothing to check for... > > vmError.cpp > ---------------- > I think the initial implementation has a bug in the following code: > > - if (fd_log != -1) { > + if (fd_log > 3) { > close(fd_log); > > I think the intention is to close the log stream if it was not stdout > (i.e. "1") or stderr (i.e. "2") but it checks for "fd_log > 3". > > I've fixed this in the downport but I'm happy to revert the fix if > somebody has a good explanation for the original code: > > - if (log.fd() != defaultStream::output_fd()) { > + if (log.fd() > 2) { > > ErrorFileRedirectTest.java > --------------------------------- > - path/package shuffling for the test library > - use "Platform.isDebugBuild()" instead of "@requires (vm.debug == > true)" which is not supported in jdk8 > - remove "-XX:-CreateCoredumpOnCrash" option because it doesn't exist in jdk 8 > - use "-XX:ErrorHandlerTest=12" instead of "-XX:ErrorHandlerTest=14" > because "14" is not available in jdk 8. But "12" still generates a > SIGSEV by reading from memory address 0. > - check for "T H R E A D" in the output because jdk 8 has no "S U M M > A R Y" section. > > The jdk 8 CSR (https://bugs.openjdk.java.net/browse/JDK-8268058) has > been reviewed and waits for approval. > > Thank you and best regards, > Volker > From zgu at redhat.com Wed Jun 2 12:56:52 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 Jun 2021 08:56:52 -0400 Subject: [8u] RFR 8196181: sun/java2d/GdiRendering/InsetClipping.java fails In-Reply-To: <379E7128-F727-498B-81E5-26661EF261A2@amazon.com> References: <379E7128-F727-498B-81E5-26661EF261A2@amazon.com> Message-ID: <52a78a03-90c1-e6c8-80eb-62430ecf2212@redhat.com> Thanks, Paul. Tagged for approval. -Zhengyu On 6/1/21 7:22 PM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Tuesday, June 1, 2021 at 12:08 PM > To: jdk8u-dev > Subject: [8u] RFR 8196181: sun/java2d/GdiRendering/InsetClipping.java fails > > I would like to backport this patch to 8u for parity with Oracle 8u311. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8196181 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/0ad172f3edb3 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8196181-8u/webrev.00/ > > The original patch does not apply cleanly. > > 1) The test is not in 8u's ProblemList.txt > 2) Copyright line conflicts in the test file. > > Test: > Updated test passed on Windows 10 and Linux x86_64 > > > Thanks, > > -Zhengyu > > From peter.zhelezniakov at bell-sw.com Thu Jun 3 06:48:02 2021 From: peter.zhelezniakov at bell-sw.com (Peter Zhelezniakov) Date: Thu, 3 Jun 2021 09:48:02 +0300 Subject: [Ping] Re: RFR [1/3]: 8057038 Speculative traps not robust when compilation and class unloading are concurrent In-Reply-To: <841F7B73-D9DF-4DCD-AE45-282220DB6EB8@amazon.com> References: <841F7B73-D9DF-4DCD-AE45-282220DB6EB8@amazon.com> Message-ID: <0A7C14F7-9191-4B4D-B7E0-F26504BAC6BE@getmailspring.com> Hi Paul, Thank you for your reviews. I've tagged these fixes for approval, and will now work on backporting the two fixes you suggest to 11u. Thanks, Peter On Apr 14 2021, at 8:39 pm, Hohensee, Paul wrote: > Lgtm. > > The other two are 8139247 and 8231501. The latter I reviewed for 8u, but isn't in 11u: there's a comment that says that 11u isn?t affected by it because 8215889 isn't in 11u. But, 8057038 also references 8215889. The latter hasn't been backported to either 8u or 11u, presumably because it fixes a concurrent class unloading issue in ZGC, and ZGC issues are being ignored in 11u. But, Shenandoah has/will have concurrent class unloading, which could very well end up in 11u, so imo both 8215889 and 8231501 should be backported to 11u as part of this series. > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Peter Zhelezniakov > Date: Tuesday, January 12, 2021 at 9:54 AM > To: "jdk8u-dev at openjdk.java.net" > Subject: [Ping] Re: RFR [1/3]: 8057038 Speculative traps not robust when compilation and class unloading are concurrent > > Any thoughts? > On Dec 22 2020, at 3:14 pm, Peter Zhelezniakov wrote: > > Hi, > > > > This is the first backport request in a series of 3: [1], [2], [3]. These fixes introduce atomicity and mutexes to Hotspot code. They help address crashes that occur in Apache Geode when running on a server with tens of CPU cores. > > The patch from jdk9 did not apply as is, some contextual changes were needed. > > This fix had a flaw that was later identified and fixed under [2]. Request for [2] is coming next in the series. > > Testing: Hotspot JTreg tests. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8057038 > > Webrev: http://cr.openjdk.java.net/~avoitylov/peterz/8057038/8057038/ > > > > > > Thanks! > > Peter > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8057038 > > [2] https://bugs.openjdk.java.net/browse/JDK-8139247 > > [3] https://bugs.openjdk.java.net/browse/JDK-8231501 > From gnu.andrew at redhat.com Fri Jun 4 04:35:03 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Jun 2021 05:35:03 +0100 Subject: [8u] RFR: 8267545: [8u] Enable Xcode 12 builds on macOS In-Reply-To: References: <4B20EB60-C4CA-42BB-A914-3CC9257F9106@amazon.com> Message-ID: <20210604043503.GA2154500@rincewind> On 22:45 Thu 27 May , Hohensee, Paul wrote: > And the webrev with the correct URLClassPath.c patch: > > https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.03/ > This only seems to have the AWTWindow.m changes: https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.03/jdk.changeset Looking at: https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.02/jdk.patch instead, apart from the URLClassPath.c duplication, I'm concerned about the j2secmod.h changes. Are these necessary? The j2secmod.h in trunk is identical to that in 8u. The addition does make sense, so it seems like it should go to trunk first under its own bug and then be backported, unless there is a good reason 8u should diverge here. The rest looks fine and I see no issue with including this as a late addition to 8u302, so the other changes for Mac OS can be utilised. As I understand Mac OS builds were broken prior to this anyway, the risk seems low. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jun 4 04:38:48 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Jun 2021 05:38:48 +0100 Subject: [IMPORTANT] 8u now OPEN for critical fixes, 8u-dev remains CLOSED Message-ID: <20210604043848.GB2154500@rincewind> 8u302-b05 has now been pushed to the 8u tree, so it is open for critical 8u302 fixes with jdk8u-critical-yes. I'm still waiting on a response from Oracle to switch 8u-dev to openjdk8u312. I will ping them tomorrow if there is no response by then. As such, the repository remains closed for now. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jun 4 04:52:09 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Jun 2021 05:52:09 +0100 Subject: OpenJDK 8u302-b04 EA Released Message-ID: <20210604045209.GD2154500@rincewind> I've made available an early access source bundle for 8u302, based on the tag jdk8u302-b04: https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b04-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b04-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint =3D CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: b4988ac7ac4da441d7bdefed93cb2ab435aa8a18c7e46bf18d66945f8935cde9 openjdk8u302-b04-ea.tar.xz 40535fe183568faecbfacc4c6a1aac72a00a0ae19bd85fb36ac0eda50adb8dc8 openjdk8u302-b04-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b04-ea.sha256 Changes in 8u302-b04: - JDK-8032050: Clean up for java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java - JDK-8043264: hsdis library not picked up correctly on expected paths - JDK-8130430: [TEST_BUG] remove unnecessary internal calls from javax/swing/JRadioButton/8075609/bug8075609.java - JDK-8206243: java -XshowSettings fails if memory.limit_in_bytes overflows LONG.max - JDK-8206925: Support the certificate_authorities extension - JDK-8228757: Fail fast if the handshake type is unknown - JDK-8242565: Policy initialization issues when the denyAfter constraint is enabled - JDK-8253375: OSX build fails with Xcode 12.0 (12A7209) - JDK-8257039: [8u] GenericTaskQueue destructor is incorrect - JDK-8262446: DragAndDrop hangs on Windows - JDK-8265666: Enable AIX build platform to make external debug symbols -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jun 4 04:53:57 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Jun 2021 05:53:57 +0100 Subject: OpenJDK 8u302-b05 EA Released Message-ID: <20210604045357.GE2154500@rincewind> I've made available an early access source bundle for 8u302, based on the tag jdk8u302-b05: https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b05-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b05-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint =3D CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 3a375df609bda84fe490e956fbc3e9d034bd274f0817b9aa2e1477d9d002e1b0 openjdk8u302-b05-ea.tar.xz 6d74b60650029f7f2c8364369bc3e8ff3af71929966e3c7a457072613a160fd7 openjdk8u302-b05-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b05-ea.sha256 Changes in 8u302-b05: - JDK-6990210: [TEST_BUG] EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java fails on gnome - JDK-7106851: Test should not use System.exit - JDK-8028618: [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails - JDK-8035000: clean up ActivationLibrary.DestroyThread - JDK-8035287: gcc warnings compiling various libraries files - JDK-8037825: Fix warnings and enable "warnings as errors" in serviceability native libraries - JDK-8043646: libosxapp.dylib fails to build on Mac OS 10.9 with clang - JDK-8047939: [TESTBUG] Rewrite test/runtime/8001071/Test8001071.sh - JDK-8074835: Resolve disabled warnings for libj2gss - JDK-8074836: Resolve disabled warnings for libosxkrb5 - JDK-8078855: [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel - JDK-8081764: [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Windows, Solaris Sparcv9 and Linux but passes on MacOSX - JDK-8172188: JDI tests fail due to "permission denied" when creating temp file - JDK-8196092: javax/swing/JComboBox/8032878/bug8032878.java fails - JDK-8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 - JDK-8239053: [8u] clean up undefined-var-template warnings - JDK-8239400: [8u] clean up undefined-var-template warnings - JDK-8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable - JDK-8250876: Fix issues with cross-compile on macos - JDK-8254631: Better support ALPN byte wire values in SunJSSE - JDK-8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod - JDK-8266723: JFR periodic events are causing extra allocations - JDK-8266929: Unable to use algorithms from 3p providers - JDK-8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash - JDK-8267426: MonitorVmStartTerminate test timed out on Embedded VM - JDK-8267689: [aarch64] Crash due to bad shift in indirect addressing mode Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hohensee at amazon.com Fri Jun 4 16:52:06 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Jun 2021 16:52:06 +0000 Subject: [8u] RFR: 8267545: [8u] Enable Xcode 12 builds on macOS Message-ID: <5FFDCD5F-32B9-4683-8E07-AFD94B15F17E@amazon.com> Thanks for the review, Andrew. New jdk webrev: https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.04/ Yes, the 03 changeset has only AWTWindow.m changes, while the webrev has all changes. Seems to have been an artifact of the webrev having been generated before the 8265238 backport push: that backport was in my local repo and I probably didn't use webrev -N. I removed the change to j2secmod.h, and verified that the Xcode 12 build still works. I've tagged 8267545 with jdk8u-critical-request and changed the Fix Version/s to openjdk8u302. Let me know which repo(s) to push to once approved: I'm assuming jdk8u. Paul ?-----Original Message----- From: Andrew Hughes Date: Thursday, June 3, 2021 at 9:36 PM To: "Hohensee, Paul" Cc: Volker Simonis , "Taylor, Ben" , jdk8u-dev Subject: RE: [8u] RFR: 8267545: [8u] Enable Xcode 12 builds on macOS On 22:45 Thu 27 May , Hohensee, Paul wrote: > And the webrev with the correct URLClassPath.c patch: > > https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.03/ > This only seems to have the AWTWindow.m changes: https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.03/jdk.changeset Looking at: https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.02/jdk.patch instead, apart from the URLClassPath.c duplication, I'm concerned about the j2secmod.h changes. Are these necessary? The j2secmod.h in trunk is identical to that in 8u. The addition does make sense, so it seems like it should go to trunk first under its own bug and then be backported, unless there is a good reason 8u should diverge here. The rest looks fine and I see no issue with including this as a late addition to 8u302, so the other changes for Mac OS can be utilised. As I understand Mac OS builds were broken prior to this anyway, the risk seems low. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jun 7 05:55:58 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 7 Jun 2021 06:55:58 +0100 Subject: [IMPORTANT] 8u-dev now OPEN Message-ID: <20210607055558.GA2268583@rincewind> 8u-dev is now open for 8u312 fixes with the label jdk8u-fix-yes. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexey at azul.com Mon Jun 7 08:04:42 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 7 Jun 2021 08:04:42 +0000 Subject: [8u] RFR: 8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error In-Reply-To: <6288092B-A420-4D6B-BE7D-8CF7453F9C56@azul.com> References: <81296A85-8148-43FF-9224-F48A9A7867B3@azul.com> <20210517141132.GD1234305@rincewind> <16E30AA2-B84E-4789-9FFE-5F3C9C888FCD@azul.com> <6288092B-A420-4D6B-BE7D-8CF7453F9C56@azul.com> Message-ID: <64F3855F-1D74-4E3B-A530-E8A318B8E3BB@azul.com> Gentle ping > On 27 May 2021, at 20:11, Alexey Bakhtin wrote: > > Hi Andrew, > > I have updated the webrev with patches generated by "hg diff? : > 11u patch for JDK-8206189: http://cr.openjdk.java.net/~abakhtin/8206189/webrev.v0/8206189.11u.patch > 8u patch for JDK-8206189: http://cr.openjdk.java.net/~abakhtin/8206189/webrev.v0/8206189.8u.patch > diff between patches: http://cr.openjdk.java.net/~abakhtin/8206189/webrev.v0/11uto8u.diff > > Regards > Alexey > >> On 18 May 2021, at 16:39, Alexey Bakhtin wrote: >> >> Hi Andrew, >> >> Thank you for review. >> It looks like an issue of the diff generated by webrev tool >> The difference between 11u and 8u patches generated by hg diff command is minimal and expected: >> >> < diff -r 53b0d5ad71db -r 038688fa32d0 src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >> < --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Wed Jul 11 14:54:35 2018 -0700 >> < +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Thu Jul 12 08:44:39 2018 +0800 >> < @@ -296,6 +296,9 @@ >> --- >>> diff -r c44b864509e2 src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java >>> --- a/src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Thu May 06 19:00:51 2021 +0300 >>> +++ b/src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Mon May 17 21:19:06 2021 +0300 >>> @@ -380,68 +383,72 @@ >> 47a48,50 >>> + if (value.length < 1 || value.length > 2) { >>> + throw new IOException("Invalid length for AlgorithmIdentifier"); >>> + } >> 99a103,105 >>> - if (value.length < 1 || value.length > 2) { >>> - throw new IOException("Invalid length for AlgorithmIdentifier"); >>> - } >>> @@ -1992,14 +1998,13 @@ >> 156c162 >> < if (contentType.equals(ContentInfo.DATA_OID)) { >> --- >>> if (contentType.equals((Object)ContentInfo.DATA_OID)) { >> 164c170 >> < } else if (contentType.equals(ContentInfo.ENCRYPTED_DATA_OID)) { >> --- >>> } else if (contentType.equals((Object)ContentInfo.ENCRYPTED_DATA_OID)) { >> >> Regards >> Alexey >> >>> On 17 May 2021, at 17:11, Andrew Hughes wrote: >>> >>> On 10:15 Mon 17 May , Alexey Bakhtin wrote: >>>> Hello, >>>> >>>> Please review the backport of DK-8206189 to 8u >>>> This is the second backport in the series required for JDK-8076190 [1] >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206189 >>>> Original patch: http://hg.openjdk.java.net/jdk/jdk11/rev/038688fa32d0 >>>> 8u webrev: http://cr.openjdk.java.net/~abakhtin/8206189/webrev.v0/ >>>> >>>> Original patch applied almost clean except for two differences: >>>> - one of the blocks is not applied cleanly because JDK-8234042 [1] already applied and JDK8 already verifies certValues length >>>> - JDK8 has a strict class cast to Object which is not necessary for JDK11 >>>> >>>> The initial review has been posted on [2] >>>> >>>> [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3054a00b5333 >>>> [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-May/013799.html >>>> >>>> Regards >>>> Alexey >>> >>> There seems to be something odd going on with the whitespace in this patch, >>> regarding the block that didn't apply cleanly. >>> >>> The 11u patch has a single addition block and a single removal block for >>> the large hunk beginning "Parse the key algorithm and then use a JCA key factory". >>> >>> The 8u patch seems to be broken up between the two, which makes them hard >>> to compare. In particular, there is the removal: >>> >>> - }, password); >>> >>> and then subsequent re-addition of: >>> >>> + }, password); >>> >>> Do the 11u & 8u versions of the file look the same after patching? >>> >>> The 8u-only block from JDK-8234042 is: >>> >>> + if (value.length < 1 || value.length > 2) { >>> + throw new IOException("Invalid length for AlgorithmIdentifier"); >>> + } >>> >>> I determined this by comparing the two patches line by line, but >>> it should really be clearer from the patch. >>> >>> Thanks, >>> -- >>> Andrew :) >>> >>> Senior Free Java Software Engineer >>> OpenJDK Package Owner >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >>> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> > From hedongbo at huawei.com Tue Jun 8 07:46:44 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Tue, 8 Jun 2021 15:46:44 +0800 Subject: [8u] RFR 8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: <9edf1421-49e7-9c3c-870a-fe04dfecebf5@huawei.com> References: <9edf1421-49e7-9c3c-870a-fe04dfecebf5@huawei.com> Message-ID: <4abcaa04-0c5c-ea39-fc10-720a225af28c@huawei.com> Gentle ping Below is the code location of the javac crash, similar to jdk11: == src/share/classes/com/sun/tools/javac/jvm/ClassReader.java 2080? final int excessSlots = 4; 2081? int expectedParameterSlots = 2082????? Code.width(sym.type.getParameterTypes()) + excessSlots;???? // sym.type.getParameterTypes() == null On 6/1/2021 2:15 PM, He Dongbo(JVM) wrote: > ping? > > On 5/21/2021 2:36 PM, He Dongbo(JVM) wrote: >> Hi, >> >> Original Bug: >> ???? https://bugs.openjdk.java.net/browse/JDK-8207160 >> ???? http://hg.openjdk.java.net/jdk/jdk/rev/e3411e5e473d >> >> Patch does not apply to 8u cleanly, because the class version in the test is 52, not 55. >> 8u webrev: http://cr.openjdk.java.net/~dongbohe/8207160/webrev.00 >> >> Tested with tier1. No regression in tests. >> >> The test in the patch passes in 8u, but but our customers reproduced this problem on 8u. The error is as follows: >> ```java >> [INFO] Compiling 347 source files to /opt/build/TransE2EFrontendService/service/nmltrans_common/../../target/classes/nmltrans_common >> An exception has occurred in the compiler (1.8.0_242). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. >> java.lang.NullPointerException >> ??????? at com.sun.tools.javac.jvm.Code.width(Code.java:279) >> ??????? at com.sun.tools.javac.jvm.ClassReader.initParameterNames(ClassReader.java:2082) >> ??????? at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2040) >> ??????? at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2252) >> ??????? at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2324) >> ??????? at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2511) >> ??????? at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2442) >> ??????? at com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) >> ??????? at com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:240) >> ??????? at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574) >> ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037) >> ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:973) >> ??????? at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:369) >> ??????? at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:365) >> ??????? at com.sun.tools.javac.comp.Resolve.findImmediateMemberType(Resolve.java:1935) >> ??????? at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:1990) >> ??????? at com.sun.tools.javac.comp.Resolve.findIdentInType(Resolve.java:2174) >> ??????? at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3412) >> ??????? at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3278) >> ??????? at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897) >> ??????? at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576) >> ??????? at com.sun.tools.javac.comp.Attr.attribType(Attr.java:638) >> ??????? at com.sun.tools.javac.comp.Attr.attribType(Attr.java:631) >> ??????? at com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:834) >> ??????? at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:558) >> ??????? at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) >> ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437) >> ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:449) >> ??????? at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:528) >> ??????? at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) >> ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437) >> ??????? at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) >> ??????? at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574) >> ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037) >> ??????? at com.sun.tools.javac.comp.Enter.complete(Enter.java:493) >> ??????? at com.sun.tools.javac.comp.Enter.main(Enter.java:471) >> ??????? at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:982) >> ??????? at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) >> ??????? at com.sun.tools.javac.main.Main.compile(Main.java:523) >> ??????? at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129) >> ??????? at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138) >> ??????? at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) >> ??????? at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174) >> ??????? at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1075) >> ??????? at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168) >> ??????? at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) >> ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) >> ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) >> ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) >> ??????? at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) >> ??????? at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) >> ??????? at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) >> ??????? at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) >> ??????? at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) >> ??????? at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) >> ??????? at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) >> ??????? at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) >> ??????? at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) >> ??????? at org.apache.maven.cli.MavenCli.main(MavenCli.java:193) >> ??????? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> ??????? at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> ??????? at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> ??????? at java.lang.reflect.Method.invoke(Method.java:498) >> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282) >> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225) >> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406) >> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347) >> ``` >> -- thanks, hedongbo From kiriyama.takuya at fujitsu.com Mon Jun 7 08:59:16 2021 From: kiriyama.takuya at fujitsu.com (kiriyama.takuya at fujitsu.com) Date: Mon, 7 Jun 2021 08:59:16 +0000 Subject: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status may cause application dead loop Message-ID: Hello, Please reply if anyone can be a sponsor. Regards, Takuya Kiriyama > -----Original Message----- > From: Kiriyama, Takuya/?? ?? > Sent: Monday, May 31, 2021 5:58 PM > To: 'jdk8u-dev at openjdk.java.net' > Subject: [8u] RFR: 8214418 half-closed SSLEngine status may cause > application dead loop > > Hi all, > > The problem reported by JDK-8214418 occurs on JDK8. > I would like to backport 8214418 patch to 8u. But I don't have a JBS account. > Could anybody help me as a sponsor of this backporting ? > > https://bugs.openjdk.java.net/browse/JDK-8214418 > https://hg.openjdk.java.net/jdk/jdk/rev/5022a4915fe9 > > I don't have access permission to > https://bugs.openjdk.java.net/browse/JDK-8214418. > I can confirm that 8214418 has been backported to JDK11. > https://bugs.openjdk.java.net/browse/JDK-8241054 > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6852be0de227 > > Original patch applied almost clean except for copyright year. > I have confirmed that the problem does not occur after backporting with 8u. > > Regards, > Takuya Kiriyama From alexey at azul.com Tue Jun 8 12:24:46 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 8 Jun 2021 12:24:46 +0000 Subject: [8u] RFR: 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 Message-ID: <9484313E-9B14-4372-9F7C-159B9E8455EF@azul.com> Hello, I?d like to backport JDK-8229243 to 8u for parity with Oracle and support for Solaris 11.4 JBS: https://bugs.openjdk.java.net/browse/JDK-8229243 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/2faeaa5933a6 8u patch: http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v0/ The patch applies almost clean except of namespace, P11Mac.java already has newer copyright year and pointer parameter field in the p11_convert.c This is the first patch in the series for Solaris 11.4 support. The following fixes are also required: JDK-8176837 [1] and JDK-8236897 [2] sun/security/pkcs11 tests passed on the Solaris 11.4 after both JDK-8229243 and JDK-8176837 patches applied [1] - https://bugs.openjdk.java.net/browse/JDK-8176837 [2] - https://bugs.openjdk.java.net/browse/JDK-8236897 Regards Alexey From alexey at azul.com Tue Jun 8 12:49:56 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 8 Jun 2021 12:49:56 +0000 Subject: [8u] RFR: 8176837: SunPKCS11 provider needs to check more details on PKCS11 Mechanism Message-ID: Hello, I?d like to backport JDK-8176837 to 8u for better support PKCS11 in Solaris 11.4 JBS: https://bugs.openjdk.java.net/browse/JDK-8176837 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/3c8f89e2ec03 8u patch : http://cr.openjdk.java.net/~abakhtin/8176837/webrev.v0 The patch applies almost clean except of namespace and extra dummyConfigId field in the SunPKCS11.java This is followup fix for JDK-8229243 [1] sun/security/pkcs11 tests passed on the Solaris 11.4 after both JDK-8229243 and JDK-8176837 patches applied [1] - https://bugs.openjdk.java.net/browse/JDK-8229243 Regards Alexey From gnu.andrew at redhat.com Wed Jun 9 03:52:40 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 04:52:40 +0100 Subject: [8u] RFR: 8267545: [8u] Enable Xcode 12 builds on macOS In-Reply-To: <5FFDCD5F-32B9-4683-8E07-AFD94B15F17E@amazon.com> References: <5FFDCD5F-32B9-4683-8E07-AFD94B15F17E@amazon.com> Message-ID: <20210609035240.GA26136@rincewind> On 16:52 Fri 04 Jun , Hohensee, Paul wrote: > Thanks for the review, Andrew. > > New jdk webrev: https://cr.openjdk.java.net/~phh/8267545/webrev.8u.jdk.04/ > > Yes, the 03 changeset has only AWTWindow.m changes, while the webrev has all changes. Seems to have been an artifact of the webrev having been generated before the 8265238 backport push: that backport was in my local repo and I probably didn't use webrev -N. > > I removed the change to j2secmod.h, and verified that the Xcode 12 build still works. > > I've tagged 8267545 with jdk8u-critical-request and changed the Fix Version/s to openjdk8u302. Let me know which repo(s) to push to once approved: I'm assuming jdk8u. > > Paul > Thanks. This version looks better. Flagged with jdk8u-critical-yes. Please push to jdk8u/jdk8u. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 03:57:32 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 04:57:32 +0100 Subject: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status may cause application dead loop In-Reply-To: References: Message-ID: <20210609035732.GB26136@rincewind> On 08:59 Mon 07 Jun , kiriyama.takuya at fujitsu.com wrote: > Hello, > > Please reply if anyone can be a sponsor. > > Regards, > Takuya Kiriyama > > > -----Original Message----- > > From: Kiriyama, Takuya/?? ?? > > Sent: Monday, May 31, 2021 5:58 PM > > To: 'jdk8u-dev at openjdk.java.net' > > Subject: [8u] RFR: 8214418 half-closed SSLEngine status may cause > > application dead loop > > > > Hi all, > > > > The problem reported by JDK-8214418 occurs on JDK8. > > I would like to backport 8214418 patch to 8u. But I don't have a JBS account. > > Could anybody help me as a sponsor of this backporting ? > > > > https://bugs.openjdk.java.net/browse/JDK-8214418 > > https://hg.openjdk.java.net/jdk/jdk/rev/5022a4915fe9 > > > > I don't have access permission to > > https://bugs.openjdk.java.net/browse/JDK-8214418. Neither do I. It looks like the bug is closed. We'll use 8241054 instead. > > I can confirm that 8214418 has been backported to JDK11. > > https://bugs.openjdk.java.net/browse/JDK-8241054 > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6852be0de227 > > > > Original patch applied almost clean except for copyright year. > > I have confirmed that the problem does not occur after backporting with 8u. Please post the patch for review and I can handle the JBS side for you. I am confused with what you mean about the copyright year as https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6852be0de227 contains no copyright year changes. > > > > Regards, > > Takuya Kiriyama > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 04:04:25 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 05:04:25 +0100 Subject: [8u] RFR: 8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error In-Reply-To: <6288092B-A420-4D6B-BE7D-8CF7453F9C56@azul.com> References: <81296A85-8148-43FF-9224-F48A9A7867B3@azul.com> <20210517141132.GD1234305@rincewind> <16E30AA2-B84E-4789-9FFE-5F3C9C888FCD@azul.com> <6288092B-A420-4D6B-BE7D-8CF7453F9C56@azul.com> Message-ID: <20210609040425.GC26136@rincewind> On 17:11 Thu 27 May , Alexey Bakhtin wrote: > Hi Andrew, > > I have updated the webrev with patches generated by "hg diff? : > 11u patch for JDK-8206189: http://cr.openjdk.java.net/~abakhtin/8206189/webrev.v0/8206189.11u.patch > 8u patch for JDK-8206189: http://cr.openjdk.java.net/~abakhtin/8206189/webrev.v0/8206189.8u.patch > diff between patches: http://cr.openjdk.java.net/~abakhtin/8206189/webrev.v0/11uto8u.diff > > Regards > Alexey > Thanks. This looks a lot better. Goodness knows what webrev did with it! I've added jdk8u-fix-yes so it can go in 8u312. Incidentally, please don't add jdk8u-fix-request until the patch has been fully reviewed, as this does clog up the approval queue and slows us down in reaching those changes that are ready to go in. There is jdk8u-needs-review for tracking patches waiting for review. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 04:08:40 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 05:08:40 +0100 Subject: [8u] RFR: 8214513: A PKCS12 keystore from Java 8 using custom PBE parameters cannot be read in Java 11 In-Reply-To: <7590543E-392B-4E6F-AA85-E9AD90576E7E@azul.com> References: <7590543E-392B-4E6F-AA85-E9AD90576E7E@azul.com> Message-ID: <20210609040840.GD26136@rincewind> On 10:24 Mon 17 May , Alexey Bakhtin wrote: > Hello, > > Please review the backport of JDK-8214513 to 8u > This is the third backport in the series required for JDK-8076190 [1] > > JBS: https://bugs.openjdk.java.net/browse/JDK-8214513 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c0f40bca91a5 > 8u webrev: http://cr.openjdk.java.net/~abakhtin/8214513/webrev.v0/ > > Patch applied clean. Small fix in the WrongPBES2.java test to load keystore using FileInputStream. > > sun/security/pkcs12 tests passed > > The initial review has been posted on [2] > > [1] https://bugs.openjdk.java.net/browse/JDK-8076190 > [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-May/013799.html > > Regards > Alexey Looks fine. Approved. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 04:15:04 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 05:15:04 +0100 Subject: [8u] RFR: 8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore In-Reply-To: <6AB4CF70-A930-416B-8044-827EA8341D3F@azul.com> References: <6AB4CF70-A930-416B-8044-827EA8341D3F@azul.com> Message-ID: <20210609041504.GE26136@rincewind> On 10:20 Mon 17 May , Alexey Bakhtin wrote: > Hello, > > Please review the backport of DK-8202837 to 8u > This is the third backport in the series required for JDK-8076190 [1] > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202837 > Original patch: http://hg.openjdk.java.net/jdk/jdk11/rev/69dc9ea17b33 > 8u webrev: http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/ > > Original patch applied almost clean except HexDumpEncoder class namespace in the com/sun/crypto/provider/PBES2Parameters.java > > The initial review has been posted on [2] > > [1] https://bugs.openjdk.java.net/browse/JDK-8076190 > [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-May/013799.html > > Regards > Alexey There's some oddity with the whitespace on this one too. Would you be able to share the hg diff output for it as well? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 04:24:14 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 05:24:14 +0100 Subject: [8u] RFR (S): 8239053: [8u] clean up undefined-var-template warnings In-Reply-To: <62CD8E50-B893-4143-AED2-6F752C6C5659@amazon.com> References: <62CD8E50-B893-4143-AED2-6F752C6C5659@amazon.com> Message-ID: <20210609042414.GF26136@rincewind> On 15:44 Fri 14 May , Hohensee, Paul wrote: > Please review this backport to 8u to enable Xcode 12 builds. The patch is a subset of the large Xcode cleanup patch for 8182299. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239053 > 8u webrev: https://cr.openjdk.java.net/~phh/8239053/webrev.8u.hotspot.00/ > > This is a private Oracle 8u261 issue, so there is no visible commit to use as a basis for the patch. There are no semantic changes, so very low risk. > > Thanks, > Paul > There are two patches for 8u with this same description. It's not clear to me how it was determined which changes went under 8239053 and which under 8239400. It also appears that 8239053 has been pushed, yet I see no jdk8u-fix-yes label and it is still in the approval queue. What is going on here? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 05:12:01 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 06:12:01 +0100 Subject: [8u] RFR: 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 In-Reply-To: <9484313E-9B14-4372-9F7C-159B9E8455EF@azul.com> References: <9484313E-9B14-4372-9F7C-159B9E8455EF@azul.com> Message-ID: <20210609051201.GG26136@rincewind> On 12:24 Tue 08 Jun , Alexey Bakhtin wrote: > Hello, > > I?d like to backport JDK-8229243 to 8u for parity with Oracle and support for Solaris 11.4 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8229243 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/2faeaa5933a6 > 8u patch: http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v0/ > > The patch applies almost clean except of namespace, P11Mac.java already has newer copyright year and pointer parameter field in the p11_convert.c > > This is the first patch in the series for Solaris 11.4 support. The following fixes are also required: JDK-8176837 [1] and JDK-8236897 [2] > > sun/security/pkcs11 tests passed on the Solaris 11.4 after both JDK-8229243 and JDK-8176837 patches applied > > [1] - https://bugs.openjdk.java.net/browse/JDK-8176837 > [2] - https://bugs.openjdk.java.net/browse/JDK-8236897 > > Regards > Alexey The p11_convert.c difference comes from JDK-8231222 [0] being in 11u first. I think that one needs backporting; 8u does fail to build if P11_DEBUG is defined. Do you want to look at that one as well or shall I? [0] https://bugs.openjdk.java.net/browse/JDK-8231222 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From volker.simonis at gmail.com Wed Jun 9 08:27:24 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Jun 2021 10:27:24 +0200 Subject: [8u] RFR (S): 8239053: [8u] clean up undefined-var-template warnings In-Reply-To: <20210609042414.GF26136@rincewind> References: <62CD8E50-B893-4143-AED2-6F752C6C5659@amazon.com> <20210609042414.GF26136@rincewind> Message-ID: On Wed, Jun 9, 2021 at 6:24 AM Andrew Hughes wrote: > > On 15:44 Fri 14 May , Hohensee, Paul wrote: > > Please review this backport to 8u to enable Xcode 12 builds. The patch is a subset of the large Xcode cleanup patch for 8182299. > > > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239053 > > 8u webrev: https://cr.openjdk.java.net/~phh/8239053/webrev.8u.hotspot.00/ > > > > This is a private Oracle 8u261 issue, so there is no visible commit to use as a basis for the patch. There are no semantic changes, so very low risk. > > > > Thanks, > > Paul > > > > There are two patches for 8u with this same description. > It's not clear to me how it was determined which changes went > under 8239053 and which under 8239400. > > It also appears that 8239053 has been pushed, yet I see no > jdk8u-fix-yes label and it is still in the approval queue. > > What is going on here? > Oracle did the two closed downports 8239053 and 8239400 which both have the same description. Because they are closed, we can not be sure what went in, we can only look at the bug description which explains which parts from the rather large change 8182299 went into 8239053 and 8239400 respectively. As you can see from the extended summary, 8239053 addresses the "undefined-var-template warnings" part from 8182299 while 8239400 addresses the "delete-non-virtual-dtor warnings" part of 8182299: https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/4962a2ce077a 8239053: [8u] clean up undefined-var-template warnings Summary: From 8182299, clean up undefined-var-template warnings http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/32dfc0a37b47 8239400: [8u] clean up undefined-var-template warnings Summary: From 8182299, clean up delete-non-virtual-dtor warnings in HotSpot I think the main cause of confusion is that Oracle has used the same description for both, 8239053 and 8239400 and Paul hasn't changed that. I can't answer why 8239053 was pushed without jdk8u-fix-yes label. That's probably just an oversight. Best regards, Volker > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akashche at redhat.com Wed Jun 9 09:57:00 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 9 Jun 2021 10:57:00 +0100 Subject: [8u] RFR: 8263311: Watch registry changes for remote printers update instead of polling Message-ID: Hi, Please review the backport of JDK-8263311 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8263311 Original change: https://github.com/openjdk/jdk/commit/a85dc557 11u backport: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5be3338cc43c 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8263311/webrev.00/ Patch doesn't apply cleanly because 8u doesn't include changes from JDK-8027771 (not public, change [1], some details [2]) in PrintServiceLookupProvider.java. Testing: checked that RemotePrinterStatusRefresh manual test passes, ran jck:api/javax_print . [1] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7b9c1e1532cf [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009564.html -- -Alex From vkempik at azul.com Wed Jun 9 11:25:28 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 9 Jun 2021 11:25:28 +0000 Subject: [8u] RFR: 8226806: [macOS 10.14] Methods of Java Robot should be called from appropriate thread Message-ID: <0C294011-9A6C-42A3-A810-A02F05AF2AEF@azul.com> Hello Please review this backport of 8226806. It wasn?t applying cleanly due to context code changes, also smart part of newer testlibrary were needed. Since the support for xcode12 were approved ( see JDK-8267545 ), it becomes important to backport some of the bug fixes as well. This fix passed all the testing in zulu8 for past 3 releases ( since October 2020) The webrev doesn?t reflect white space changes in CRobot.m, so the patch looks smaller than original. The webrev: http://cr.openjdk.java.net/~vkempik/8226806/webrev.01/ The bug: https://bugs.openjdk.java.net/browse/JDK-8226806 The orignal patch: https://hg.openjdk.java.net/jdk/jdk/rev/23dc143cca50 Thanks in advance, Vladimir. From alexey at azul.com Wed Jun 9 11:46:59 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 9 Jun 2021 11:46:59 +0000 Subject: [8u] RFR: 8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore In-Reply-To: <20210609041504.GE26136@rincewind> References: <6AB4CF70-A930-416B-8044-827EA8341D3F@azul.com> <20210609041504.GE26136@rincewind> Message-ID: Hello Andrew, Thank you for review. The diff between 11u and 8u patches generated by ?hg diff? is here : http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/8202837.11to8.diff 11u and 8u versions are almost identical. 11u patch : http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/8202837.11u.diff 8u patch: http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/8202837.8u.diff Regards Alexey > On 9 Jun 2021, at 07:15, Andrew Hughes wrote: > > On 10:20 Mon 17 May , Alexey Bakhtin wrote: >> Hello, >> >> Please review the backport of DK-8202837 to 8u >> This is the third backport in the series required for JDK-8076190 [1] >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202837 >> Original patch: http://hg.openjdk.java.net/jdk/jdk11/rev/69dc9ea17b33 >> 8u webrev: http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/ >> >> Original patch applied almost clean except HexDumpEncoder class namespace in the com/sun/crypto/provider/PBES2Parameters.java >> >> The initial review has been posted on [2] >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8076190 >> [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-May/013799.html >> >> Regards >> Alexey > > There's some oddity with the whitespace on this one too. > Would you be able to share the hg diff output for it as well? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From zgu at redhat.com Wed Jun 9 13:37:53 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 9 Jun 2021 09:37:53 -0400 Subject: [8u] RFR 8196093: javax/swing/JComboBox/8072767/bug8072767.java fails Message-ID: <1ad4b6c4-a0bf-3d3e-a427-0c5c04bf0d49@redhat.com> I would like to backport this patch to 8u. This patch fixes test failure of 8u parity backport JDK-8072767 The original bug: https://bugs.openjdk.java.net/browse/JDK-8196093 The original patch: https://github.com/openjdk/jdk/commit/513269d2 The backport is mostly clean, except the test is not in 8u's ProblemList. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8196093-8u/webrev.00/ The patch contains JDK-8072767 as this patch is followup fix of JDK-8072767 and I expect to push them together once approved. Test: Passed tests in patch. Thanks, -Zhengyu From alexey at azul.com Wed Jun 9 14:10:43 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 9 Jun 2021 14:10:43 +0000 Subject: [8u] RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces Message-ID: Hello, Please review the backport of JDK-8231222 to 8u This backport is required for clean JDK-8229243 [1] backport JBS: https://bugs.openjdk.java.net/browse/JDK-8231222 Original patch : https://hg.openjdk.java.net/jdk/jdk/rev/49836127542b 8u patch: http://cr.openjdk.java.net/~abakhtin/8231222/webrev.v0/ Original patch applies almost clean except of src code location and copyright date in the p11_general.c file Tested with sun/security/pkcs11 tests and P11_DEBUG flag enabled [1] - https://bugs.openjdk.java.net/browse/JDK-8229243 Regards Alexey From alexey at azul.com Wed Jun 9 14:39:58 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 9 Jun 2021 14:39:58 +0000 Subject: [8u] RFR: 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 In-Reply-To: <20210609051201.GG26136@rincewind> References: <9484313E-9B14-4372-9F7C-159B9E8455EF@azul.com> <20210609051201.GG26136@rincewind> Message-ID: <73B20A00-3815-4EFF-8A45-8BC4D79827D6@azul.com> Hello Andrew, Thank you for review. I?ve submitted review for the JDK-8231222 [1] I have updated the patch for this backport on the base of JDK-8231222 backport : http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/ Now the patch is almost clean except of copyright year in P11Mac.java (current version already has newer copyright year) Difference in the 11u and 8u patches are : http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/8229243.11to8.diff 11u diff : http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/8229243.11u.diff 8u diff : 11u diff : http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/8229243.8u.diff [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-June/013978.html Regards Alexey > > The p11_convert.c difference comes from JDK-8231222 [0] being in > 11u first. I think that one needs backporting; 8u does fail to > build if P11_DEBUG is defined. > > Do you want to look at that one as well or shall I? > > [0] https://bugs.openjdk.java.net/browse/JDK-8231222 > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 16:31:40 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 17:31:40 +0100 Subject: [8u] RFR (S): 8239053: [8u] clean up undefined-var-template warnings In-Reply-To: References: <62CD8E50-B893-4143-AED2-6F752C6C5659@amazon.com> <20210609042414.GF26136@rincewind> Message-ID: <20210609163140.GA63768@rincewind> On 10:27 Wed 09 Jun , Volker Simonis wrote: > On Wed, Jun 9, 2021 at 6:24 AM Andrew Hughes wrote: > > > > On 15:44 Fri 14 May , Hohensee, Paul wrote: > > > Please review this backport to 8u to enable Xcode 12 builds. The patch is a subset of the large Xcode cleanup patch for 8182299. > > > > > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239053 > > > 8u webrev: https://cr.openjdk.java.net/~phh/8239053/webrev.8u.hotspot.00/ > > > > > > This is a private Oracle 8u261 issue, so there is no visible commit to use as a basis for the patch. There are no semantic changes, so very low risk. > > > > > > Thanks, > > > Paul > > > > > > > There are two patches for 8u with this same description. > > It's not clear to me how it was determined which changes went > > under 8239053 and which under 8239400. > > > > It also appears that 8239053 has been pushed, yet I see no > > jdk8u-fix-yes label and it is still in the approval queue. > > > > What is going on here? > > > > Oracle did the two closed downports 8239053 and 8239400 which both > have the same description. Because they are closed, we can not be sure > what went in, we can only look at the bug description which explains > which parts from the rather large change 8182299 went into 8239053 and > 8239400 respectively. > Right, I got that much :) I'd seen those bugs before and got that far. > As you can see from the extended summary, 8239053 addresses the > "undefined-var-template warnings" part from 8182299 while 8239400 > addresses the "delete-non-virtual-dtor warnings" part of 8182299: > > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/4962a2ce077a > 8239053: [8u] clean up undefined-var-template warnings > Summary: From 8182299, clean up undefined-var-template warnings > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/32dfc0a37b47 > 8239400: [8u] clean up undefined-var-template warnings > Summary: From 8182299, clean up delete-non-virtual-dtor warnings in HotSpot > > I think the main cause of confusion is that Oracle has used the same > description for both, 8239053 and 8239400 and Paul hasn't changed > that. Ok, I hadn't seen that. It does make more sense now how the patches were developed. > > I can't answer why 8239053 was pushed without jdk8u-fix-yes label. > That's probably just an oversight. > Yes. I can retrospectively approve, but this shouldn't happen in future. > Best regards, > Volker > > > Thanks, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > OpenJDK Package Owner > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 16:42:58 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 17:42:58 +0100 Subject: [8u] RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces In-Reply-To: References: Message-ID: <20210609164258.GB63768@rincewind> On 14:10 Wed 09 Jun , Alexey Bakhtin wrote: > Hello, > > Please review the backport of JDK-8231222 to 8u > This backport is required for clean JDK-8229243 [1] backport > > JBS: https://bugs.openjdk.java.net/browse/JDK-8231222 > Original patch : https://hg.openjdk.java.net/jdk/jdk/rev/49836127542b > 8u patch: http://cr.openjdk.java.net/~abakhtin/8231222/webrev.v0/ > > Original patch applies almost clean except of src code location and copyright date in the p11_general.c file > > Tested with sun/security/pkcs11 tests and P11_DEBUG flag enabled > > [1] - https://bugs.openjdk.java.net/browse/JDK-8229243 > > Regards > Alexey Thanks for looking into this one so quickly. Patch looks fine and I can confirm 8u now builds with P11_DEBUG enabled. Please flag with jdk8u-fix-request for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 16:50:05 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 17:50:05 +0100 Subject: [8u] RFR: 8263311: Watch registry changes for remote printers update instead of polling In-Reply-To: References: Message-ID: <20210609165005.GC63768@rincewind> On 10:57 Wed 09 Jun , Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8263311 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8263311 > > Original change: https://github.com/openjdk/jdk/commit/a85dc557 > > 11u backport: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5be3338cc43c > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8263311/webrev.00/ > > Patch doesn't apply cleanly because 8u doesn't include changes from > JDK-8027771 (not public, change [1], some details [2]) in > PrintServiceLookupProvider.java. Testing: checked that > RemotePrinterStatusRefresh manual test passes, ran jck:api/javax_print > . > > > [1] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7b9c1e1532cf > [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009564.html > > -- > -Alex > Changes look sensible. Please for approval with jdk8u-fix-request. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From volker.simonis at gmail.com Wed Jun 9 17:03:57 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Jun 2021 19:03:57 +0200 Subject: [8u] RFR (S): 8239053: [8u] clean up undefined-var-template warnings In-Reply-To: <20210609163140.GA63768@rincewind> References: <62CD8E50-B893-4143-AED2-6F752C6C5659@amazon.com> <20210609042414.GF26136@rincewind> <20210609163140.GA63768@rincewind> Message-ID: On Wed, Jun 9, 2021 at 6:31 PM Andrew Hughes wrote: > > On 10:27 Wed 09 Jun , Volker Simonis wrote: > > On Wed, Jun 9, 2021 at 6:24 AM Andrew Hughes wrote: > > > > > > On 15:44 Fri 14 May , Hohensee, Paul wrote: > > > > Please review this backport to 8u to enable Xcode 12 builds. The patch is a subset of the large Xcode cleanup patch for 8182299. > > > > > > > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8239053 > > > > 8u webrev: https://cr.openjdk.java.net/~phh/8239053/webrev.8u.hotspot.00/ > > > > > > > > This is a private Oracle 8u261 issue, so there is no visible commit to use as a basis for the patch. There are no semantic changes, so very low risk. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > > There are two patches for 8u with this same description. > > > It's not clear to me how it was determined which changes went > > > under 8239053 and which under 8239400. > > > > > > It also appears that 8239053 has been pushed, yet I see no > > > jdk8u-fix-yes label and it is still in the approval queue. > > > > > > What is going on here? > > > > > > > Oracle did the two closed downports 8239053 and 8239400 which both > > have the same description. Because they are closed, we can not be sure > > what went in, we can only look at the bug description which explains > > which parts from the rather large change 8182299 went into 8239053 and > > 8239400 respectively. > > > > Right, I got that much :) > > I'd seen those bugs before and got that far. > > > As you can see from the extended summary, 8239053 addresses the > > "undefined-var-template warnings" part from 8182299 while 8239400 > > addresses the "delete-non-virtual-dtor warnings" part of 8182299: > > > > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/4962a2ce077a > > 8239053: [8u] clean up undefined-var-template warnings > > Summary: From 8182299, clean up undefined-var-template warnings > > > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/32dfc0a37b47 > > 8239400: [8u] clean up undefined-var-template warnings > > Summary: From 8182299, clean up delete-non-virtual-dtor warnings in HotSpot > > > > I think the main cause of confusion is that Oracle has used the same > > description for both, 8239053 and 8239400 and Paul hasn't changed > > that. > > Ok, I hadn't seen that. It does make more sense now how the patches were > developed. > > > > > I can't answer why 8239053 was pushed without jdk8u-fix-yes label. > > That's probably just an oversight. > > > > Yes. I can retrospectively approve, but this shouldn't happen in future. > Thanks! Paul is on vacation this week but I'll brief him on that :) > > Best regards, > > Volker > > > > > Thanks, > > > -- > > > Andrew :) > > > > > > Senior Free Java Software Engineer > > > OpenJDK Package Owner > > > Red Hat, Inc. (http://www.redhat.com) > > > > > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > > > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akashche at redhat.com Wed Jun 9 17:05:19 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 9 Jun 2021 18:05:19 +0100 Subject: [8u] RFR: 8263311: Watch registry changes for remote printers update instead of polling In-Reply-To: <20210609165005.GC63768@rincewind> References: <20210609165005.GC63768@rincewind> Message-ID: On 6/9/21, Andrew Hughes wrote: > On 10:57 Wed 09 Jun , Alex Kashchenko wrote: >> Hi, >> >> Please review the backport of JDK-8263311 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8263311 >> >> Original change: https://github.com/openjdk/jdk/commit/a85dc557 >> >> 11u backport: >> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5be3338cc43c >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8263311/webrev.00/ >> >> Patch doesn't apply cleanly because 8u doesn't include changes from >> JDK-8027771 (not public, change [1], some details [2]) in >> PrintServiceLookupProvider.java. Testing: checked that >> RemotePrinterStatusRefresh manual test passes, ran jck:api/javax_print >> . >> >> >> [1] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7b9c1e1532cf >> [2] >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009564.html >> >> -- >> -Alex >> > > Changes look sensible. Please for approval with jdk8u-fix-request. Thanks for the review! I've added the label to the issue. -- -Alex From gnu.andrew at redhat.com Wed Jun 9 17:18:24 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 18:18:24 +0100 Subject: [8u] RFR: 8226806: [macOS 10.14] Methods of Java Robot should be called from appropriate thread In-Reply-To: <0C294011-9A6C-42A3-A810-A02F05AF2AEF@azul.com> References: <0C294011-9A6C-42A3-A810-A02F05AF2AEF@azul.com> Message-ID: <20210609171824.GD63768@rincewind> On 11:25 Wed 09 Jun , Vladimir Kempik wrote: > Hello > Please review this backport of 8226806. > It wasn?t applying cleanly due to context code changes, also smart part of newer testlibrary were needed. > Since the support for xcode12 were approved ( see JDK-8267545 ), it becomes important to backport some of the bug fixes as well. > This fix passed all the testing in zulu8 for past 3 releases ( since October 2020) > > The webrev doesn?t reflect white space changes in CRobot.m, so the patch looks smaller than original. > > The webrev: http://cr.openjdk.java.net/~vkempik/8226806/webrev.01/ > The bug: https://bugs.openjdk.java.net/browse/JDK-8226806 > The orignal patch: https://hg.openjdk.java.net/jdk/jdk/rev/23dc143cca50 > > Thanks in advance, Vladimir. Regarding bug fixes, would it be worth bringing in JDK-8155740 & JDK-8156460? I believe these would remove the differences in the keyEvent code. The test library additions seem odd, given those methods are already in jdk/test/lib/jdk/test/lib/process/OutputAnalyzer.java. I don't know why we have two OutputAnalyzer.java files, but that also seems to be true in 11u! Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 17:19:59 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 18:19:59 +0100 Subject: [8u] RFR: 8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore In-Reply-To: References: <6AB4CF70-A930-416B-8044-827EA8341D3F@azul.com> <20210609041504.GE26136@rincewind> Message-ID: <20210609171959.GE63768@rincewind> On 11:46 Wed 09 Jun , Alexey Bakhtin wrote: > Hello Andrew, > > Thank you for review. > The diff between 11u and 8u patches generated by ?hg diff? is here : http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/8202837.11to8.diff > 11u and 8u versions are almost identical. > 11u patch : http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/8202837.11u.diff > 8u patch: http://cr.openjdk.java.net/~abakhtin/8202837/webrev.v0/8202837.8u.diff > > Regards > Alexey > Yes, that looks a lot more like what I expected from the comments! Approved for 8u312. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 17:31:44 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 18:31:44 +0100 Subject: [8u] RFR (S): 8239053: [8u] clean up undefined-var-template warnings In-Reply-To: References: <62CD8E50-B893-4143-AED2-6F752C6C5659@amazon.com> <20210609042414.GF26136@rincewind> <20210609163140.GA63768@rincewind> Message-ID: <20210609173144.GA82480@rincewind> On 19:03 Wed 09 Jun , Volker Simonis wrote: snip... > > Thanks! > Paul is on vacation this week but I'll brief him on that :) > Thanks. I'm sure he's well aware already, and probably just got over-excited with the prospect of working Mac builds ;-) -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 17:35:32 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 18:35:32 +0100 Subject: [8u] RFR: 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 In-Reply-To: <73B20A00-3815-4EFF-8A45-8BC4D79827D6@azul.com> References: <9484313E-9B14-4372-9F7C-159B9E8455EF@azul.com> <20210609051201.GG26136@rincewind> <73B20A00-3815-4EFF-8A45-8BC4D79827D6@azul.com> Message-ID: <20210609173532.GB82480@rincewind> On 14:39 Wed 09 Jun , Alexey Bakhtin wrote: > Hello Andrew, > > Thank you for review. > I?ve submitted review for the JDK-8231222 [1] > > I have updated the patch for this backport on the base of JDK-8231222 backport : > http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/ > > Now the patch is almost clean except of copyright year in P11Mac.java (current version already has newer copyright year) > > Difference in the 11u and 8u patches are : http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/8229243.11to8.diff > 11u diff : http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/8229243.11u.diff > 8u diff : 11u diff : http://cr.openjdk.java.net/~abakhtin/8229243/webrev.v1/8229243.8u.diff > > > [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-June/013978.html > > Regards > Alexey > Thanks. This one looks good to go now. Please flag with jdk8u-fix-request. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 9 17:39:39 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 Jun 2021 18:39:39 +0100 Subject: [8u] RFR 8196093: javax/swing/JComboBox/8072767/bug8072767.java fails In-Reply-To: <1ad4b6c4-a0bf-3d3e-a427-0c5c04bf0d49@redhat.com> References: <1ad4b6c4-a0bf-3d3e-a427-0c5c04bf0d49@redhat.com> Message-ID: <20210609173939.GC82480@rincewind> On 09:37 Wed 09 Jun , Zhengyu Gu wrote: > I would like to backport this patch to 8u. This patch fixes test failure of > 8u parity backport JDK-8072767 > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8196093 > The original patch: https://github.com/openjdk/jdk/commit/513269d2 > > The backport is mostly clean, except the test is not in 8u's ProblemList. > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8196093-8u/webrev.00/ > > The patch contains JDK-8072767 as this patch is followup fix of JDK-8072767 > and I expect to push them together once approved. > > Test: > Passed tests in patch. > > Thanks, > > -Zhengyu > Can we just have one patch in a webrev please? I had to delete 8072767 in order to review this. 8072767 has been approved and so can already be pushed. 8196093 is not in 11u yet, so should go there first. I also see 8264328: "Broken license in javax/swing/JComboBox/8072767/bug8072767.java" which may be relevant. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hedongbo at huawei.com Thu Jun 10 03:22:20 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Thu, 10 Jun 2021 11:22:20 +0800 Subject: [8u] RFR 8268444: keytool -v -list print is incorrect after backport JDK-8141457 Message-ID: Hi, Please review this patch, it deletes the extra item ` ({9,number,#})` in printX509Cert. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8268444 webrev: http://cr.openjdk.java.net/~dongbohe/8268444/webrev.00/ Although the item ` ({9,number,#})` is included in JDK-8141457[1], it has been deleted in JDK-8171319[2]. Because JDK-8171319 has been integrated JDK8, so we need to delete the item ` ({9,number,#})` in JDK8. Testing: worked correctly after patch. ? [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/97b25277c28f#l2.16 [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1ccb32228fe7#l4.8 -- thanks, hedongbo From hedongbo at huawei.com Thu Jun 10 03:24:19 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Thu, 10 Jun 2021 11:24:19 +0800 Subject: [8u] RFR 8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: <4abcaa04-0c5c-ea39-fc10-720a225af28c@huawei.com> References: <9edf1421-49e7-9c3c-870a-fe04dfecebf5@huawei.com> <4abcaa04-0c5c-ea39-fc10-720a225af28c@huawei.com> Message-ID: <0c62a752-e0f7-f9bc-72a2-a284fe69847f@huawei.com> cc compiler-dev@ Can I get some advice from reviewers? On 6/8/2021 3:46 PM, He Dongbo(JVM) wrote: > Gentle ping > > Below is the code location of the javac crash, similar to jdk11: > == > src/share/classes/com/sun/tools/javac/jvm/ClassReader.java > 2080? final int excessSlots = 4; > 2081? int expectedParameterSlots = > 2082????? Code.width(sym.type.getParameterTypes()) + excessSlots;???? // sym.type.getParameterTypes() == null > > On 6/1/2021 2:15 PM, He Dongbo(JVM) wrote: >> ping? >> >> On 5/21/2021 2:36 PM, He Dongbo(JVM) wrote: >>> Hi, >>> >>> Original Bug: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8207160 >>> ???? http://hg.openjdk.java.net/jdk/jdk/rev/e3411e5e473d >>> >>> Patch does not apply to 8u cleanly, because the class version in the test is 52, not 55. >>> 8u webrev: http://cr.openjdk.java.net/~dongbohe/8207160/webrev.00 >>> >>> Tested with tier1. No regression in tests. >>> >>> The test in the patch passes in 8u, but but our customers reproduced this problem on 8u. The error is as follows: >>> ```java >>> [INFO] Compiling 347 source files to /opt/build/TransE2EFrontendService/service/nmltrans_common/../../target/classes/nmltrans_common >>> An exception has occurred in the compiler (1.8.0_242). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. >>> java.lang.NullPointerException >>> ??????? at com.sun.tools.javac.jvm.Code.width(Code.java:279) >>> ??????? at com.sun.tools.javac.jvm.ClassReader.initParameterNames(ClassReader.java:2082) >>> ??????? at com.sun.tools.javac.jvm.ClassReader.readMethod(ClassReader.java:2040) >>> ??????? at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2252) >>> ??????? at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2324) >>> ??????? at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2511) >>> ??????? at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2442) >>> ??????? at com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76) >>> ??????? at com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:240) >>> ??????? at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574) >>> ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037) >>> ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:973) >>> ??????? at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:369) >>> ??????? at com.sun.tools.javac.comp.Resolve.isAccessible(Resolve.java:365) >>> ??????? at com.sun.tools.javac.comp.Resolve.findImmediateMemberType(Resolve.java:1935) >>> ??????? at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:1990) >>> ??????? at com.sun.tools.javac.comp.Resolve.findIdentInType(Resolve.java:2174) >>> ??????? at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3412) >>> ??????? at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3278) >>> ??????? at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897) >>> ??????? at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576) >>> ??????? at com.sun.tools.javac.comp.Attr.attribType(Attr.java:638) >>> ??????? at com.sun.tools.javac.comp.Attr.attribType(Attr.java:631) >>> ??????? at com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:834) >>> ??????? at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:558) >>> ??????? at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) >>> ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437) >>> ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:449) >>> ??????? at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:528) >>> ??????? at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) >>> ??????? at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437) >>> ??????? at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) >>> ??????? at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574) >>> ??????? at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037) >>> ??????? at com.sun.tools.javac.comp.Enter.complete(Enter.java:493) >>> ??????? at com.sun.tools.javac.comp.Enter.main(Enter.java:471) >>> ??????? at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:982) >>> ??????? at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) >>> ??????? at com.sun.tools.javac.main.Main.compile(Main.java:523) >>> ??????? at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129) >>> ??????? at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138) >>> ??????? at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) >>> ??????? at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174) >>> ??????? at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1075) >>> ??????? at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168) >>> ??????? at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) >>> ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) >>> ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) >>> ??????? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) >>> ??????? at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) >>> ??????? at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) >>> ??????? at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) >>> ??????? at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) >>> ??????? at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) >>> ??????? at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) >>> ??????? at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) >>> ??????? at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) >>> ??????? at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) >>> ??????? at org.apache.maven.cli.MavenCli.main(MavenCli.java:193) >>> ??????? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> ??????? at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> ??????? at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> ??????? at java.lang.reflect.Method.invoke(Method.java:498) >>> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282) >>> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225) >>> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406) >>> ??????? at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347) >>> ``` >>> -- thanks, hedongbo From sgehwolf at redhat.com Thu Jun 10 09:16:22 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Jun 2021 11:16:22 +0200 Subject: [8u] RFR 8268444: keytool -v -list print is incorrect after backport JDK-8141457 In-Reply-To: References: Message-ID: <23592efc1680fa2505740ff4ed08867dad3f4ad7.camel@redhat.com> Hi, On Thu, 2021-06-10 at 11:22 +0800, He Dongbo(JVM) wrote: > Hi, > > Please review this patch, it deletes the extra item ` ({9,number,#})` in printX509Cert. > ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8268444 Nice find! > webrev: http://cr.openjdk.java.net/~dongbohe/8268444/webrev.00/ > > Although the item ` ({9,number,#})` is included in JDK-8141457[1], it has been deleted in JDK-8171319[2]. > Because JDK-8171319 has been integrated JDK8, so we need to delete the item ` ({9,number,#})` in JDK8. > > Testing: worked correctly after patch. > Looks good. This seems like something we should include in the 8u302 update. It's pretty low risk. Please flag with jdk8u-critical-request if you agree. Thanks, Severin > ? > [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/97b25277c28f#l2.16 > [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1ccb32228fe7#l4.8 > From alexey at azul.com Thu Jun 10 09:23:10 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 10 Jun 2021 09:23:10 +0000 Subject: [8u] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Message-ID: <19774E77-4E81-4A48-8C4A-0308128A38BE@azul.com> Hello, Could you please review the backport of JDK-8241248 to 8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 11u patch : https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5d4535b3a2fe 8u patch : http://cr.openjdk.java.net/~abakhtin/8241248.8u/webrev.v0/ 11u patch is not applied clean because of different source file location. The rest is clean Test from the bug report is passed sun/security/ssl and javax/net/ssl jtreg tests passed Regards Alexey From hedongbo at huawei.com Thu Jun 10 09:42:00 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Thu, 10 Jun 2021 17:42:00 +0800 Subject: [8u] RFR 8268444: keytool -v -list print is incorrect after backport JDK-8141457 In-Reply-To: <23592efc1680fa2505740ff4ed08867dad3f4ad7.camel@redhat.com> References: <23592efc1680fa2505740ff4ed08867dad3f4ad7.camel@redhat.com> Message-ID: Thank you for your review, sgehwolf.? Tagged. On 6/10/2021 5:16 PM, Severin Gehwolf wrote: > Hi, > > On Thu, 2021-06-10 at 11:22 +0800, He Dongbo(JVM) wrote: >> Hi, >> >> Please review this patch, it deletes the extra item ` ({9,number,#})` in printX509Cert. >> ? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8268444 > Nice find! > >> webrev: http://cr.openjdk.java.net/~dongbohe/8268444/webrev.00/ >> >> Although the item ` ({9,number,#})` is included in JDK-8141457[1], it has been deleted in JDK-8171319[2]. >> Because JDK-8171319 has been integrated JDK8, so we need to delete the item ` ({9,number,#})` in JDK8. >> >> Testing: worked correctly after patch. >> > Looks good. > > This seems like something we should include in the 8u302 update. It's > pretty low risk. Please flag with jdk8u-critical-request if you agree. > > Thanks, > Severin > >> ? >> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/97b25277c28f#l2.16 >> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1ccb32228fe7#l4.8 >> > > > . -- thanks, hedongbo From zgu at redhat.com Thu Jun 10 12:34:49 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 10 Jun 2021 08:34:49 -0400 Subject: [8u] RFR 8196093: javax/swing/JComboBox/8072767/bug8072767.java fails In-Reply-To: <20210609173939.GC82480@rincewind> References: <1ad4b6c4-a0bf-3d3e-a427-0c5c04bf0d49@redhat.com> <20210609173939.GC82480@rincewind> Message-ID: <76ebd434-7997-acc0-377b-dd519a622bd1@redhat.com> Hi Andrew, On 6/9/21 1:39 PM, Andrew Hughes wrote: > On 09:37 Wed 09 Jun , Zhengyu Gu wrote: >> I would like to backport this patch to 8u. This patch fixes test failure of >> 8u parity backport JDK-8072767 >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8196093 >> The original patch: https://github.com/openjdk/jdk/commit/513269d2 >> >> The backport is mostly clean, except the test is not in 8u's ProblemList. >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8196093-8u/webrev.00/ >> >> The patch contains JDK-8072767 as this patch is followup fix of JDK-8072767 >> and I expect to push them together once approved. >> >> Test: >> Passed tests in patch. >> >> Thanks, >> >> -Zhengyu >> > > Can we just have one patch in a webrev please? I had to delete 8072767 in > order to review this. 8072767 has been approved and so can already be pushed. > JDK-8196093 only patch: http://cr.openjdk.java.net/~zgu/JDK-8196093-8u/webrev.01/ > 8196093 is not in 11u yet, so should go there first. I also see I will take on 11u backport ... Thanks, -Zhengyu > 8264328: "Broken license in javax/swing/JComboBox/8072767/bug8072767.java" > which may be relevant. > > Thanks, > From zgu at redhat.com Fri Jun 11 21:18:31 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 11 Jun 2021 17:18:31 -0400 Subject: [8u] RFR 8196093: javax/swing/JComboBox/8072767/bug8072767.java fails In-Reply-To: <76ebd434-7997-acc0-377b-dd519a622bd1@redhat.com> References: <1ad4b6c4-a0bf-3d3e-a427-0c5c04bf0d49@redhat.com> <20210609173939.GC82480@rincewind> <76ebd434-7997-acc0-377b-dd519a622bd1@redhat.com> Message-ID: Hi Andrew, > >> 8196093 is not in 11u yet, so should go there first. I also see > I will take on 11u backport ... I could not reproduce in 11u the test failure without the patch. Thanks, -Zhengyu > > Thanks, > > -Zhengyu > > >> 8264328: "Broken license in >> javax/swing/JComboBox/8072767/bug8072767.java" >> which may be relevant. >> >> Thanks, >> From hohensee at amazon.com Mon Jun 14 16:10:34 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 14 Jun 2021 16:10:34 +0000 Subject: [8u] RFR (S): 8239053: [8u] clean up undefined-var-template warnings Message-ID: You nailed that one, Andrew. :) Apologies for the mixup. According to https://mail.openjdk.java.net/pipermail/jdk8u-dev-changes/2021-May/004258.html I had both patches in my dev repo and inadvertently pushed them together. My bad, and thanks for the retrospective approval. Paul ?-----Original Message----- From: Andrew Hughes Date: Wednesday, June 9, 2021 at 10:32 AM To: Volker Simonis Cc: "Hohensee, Paul" , jdk8u-dev Subject: RE: [8u] RFR (S): 8239053: [8u] clean up undefined-var-template warnings On 19:03 Wed 09 Jun , Volker Simonis wrote: snip... > > Thanks! > Paul is on vacation this week but I'll brief him on that :) > Thanks. I'm sure he's well aware already, and probably just got over-excited with the prospect of working Mac builds ;-) -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From zgu at redhat.com Mon Jun 21 17:42:58 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 21 Jun 2021 13:42:58 -0400 Subject: [8u] RFR 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection Message-ID: I would like to backport this patch to openjdk8u for parity with Oracle 8u291. The original patch does not apply cleanly, but conflicts are minor. - Both files conflict on copyright years - Another conflict in URLStreamHandler.java due to line shifts Original bug: https://bugs.openjdk.java.net/browse/JDK-7146776 Original patch: https://github.com/openjdk/jdk/commit/db9c114d 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-7146776-8u/webrev.00/ Test: jdk_net Thanks, -Zhengyu From sgehwolf at redhat.com Tue Jun 22 08:57:33 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 22 Jun 2021 10:57:33 +0200 Subject: [8u] RFR 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection In-Reply-To: References: Message-ID: <70639d2762b774d9fd5d8df4664e311a0cc552af.camel@redhat.com> On Mon, 2021-06-21 at 13:42 -0400, Zhengyu Gu wrote: > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-7146776-8u/webrev.00/ This looks good to me. Thanks, Severin From zgu at redhat.com Tue Jun 22 11:53:32 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jun 2021 07:53:32 -0400 Subject: [8u] RFR 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection In-Reply-To: <70639d2762b774d9fd5d8df4664e311a0cc552af.camel@redhat.com> References: <70639d2762b774d9fd5d8df4664e311a0cc552af.camel@redhat.com> Message-ID: Thanks for quite reviewing, Severin. Tagged for approval. -Zhengyu On 6/22/21 4:57 AM, Severin Gehwolf wrote: > On Mon, 2021-06-21 at 13:42 -0400, Zhengyu Gu wrote: >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-7146776-8u/webrev.00/ > > This looks good to me. > > Thanks, > Severin > From alexey at azul.com Tue Jun 22 12:42:31 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 22 Jun 2021 12:42:31 +0000 Subject: [8u] RFR: 8183107: PKCS11 regression regarding checkKeySize Message-ID: Hello, Could you please review backport JDK-8183107 to 8u JBS: https://bugs.openjdk.java.net/browse/JDK-8183107 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/9a9226f590a7 8u patch: http://cr.openjdk.java.net/~abakhtin/8183107/webrev.v0/ 11u patch applies almost clean except of copyright year in the P11Signature.java file sun/security/pkcs11 test passed without regression Regards Alexey From jvanek at redhat.com Tue Jun 22 13:56:52 2021 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 22 Jun 2021 15:56:52 +0200 Subject: Wno-error=format-overflow needed onnewer gccs Message-ID: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> Hello! For pretty long tim, on newer gcc default build fails as: Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parse3.cpp /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp: In static member function ?static void os::Linux::check_signal_handler(int)?: /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp:4999:15: error: ?%s? directive argument is null [-Werror=format-overflow=] 4999 | tty->print("Warning: %s handler ", exception_name(sig, buf, O_BUFLEN)); | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parseHelper.cpp cc1plus: all warnings being treated as errors gmake[6]: *** [/home/jvanek/hg/jdk8u-dev/hotspot/make/linux/makefiles/rules.make:151: os_linux.o] Error 1 You need to build as make WARNINGS_ARE_ERRORS="-Wno-error=format-overflow" to make it works. I'm unabel to decide if the warning is valid. If it is, can you please fix it? If not, I can make webrev and adding it to default set of hotspot's excluded warnings. J. If somebody is sitting on it right now, feel free to push on you own :) the above exclusion is making the jdk to build: make WARNINGS_ARE_ERRORS="-Wno-error=format-overflow" ... ----- Build times ------- Start 2021-06-22 15:49:22 End 2021-06-22 15:51:05 00:00:00 corba 00:00:00 hotspot 00:00:00 jaxp 00:00:00 jaxws 00:01:43 jdk 00:00:00 langtools 00:01:43 TOTAL ------------------------- Finished building OpenJDK for target 'default' -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From zgu at redhat.com Tue Jun 22 14:20:09 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jun 2021 10:20:09 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. Message-ID: I would like to backport this patch to openjdk8u for parity with Oracle 8u291. The original patch does not apply cleanly. - openjdk8u does not have arm (32-bit) port, striped arm specific changes from the patch. - "precond" macro is not defined in openjdk8u, replaced with assert(...). Original bug: https://bugs.openjdk.java.net/browse/JDK-8248901 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.00/ Thanks, -Zhengyu From adinn at redhat.com Wed Jun 23 08:46:02 2021 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 23 Jun 2021 09:46:02 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: References: Message-ID: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> Hi Zhengyu, On 22/06/2021 15:20, Zhengyu Gu wrote: > I would like to backport this patch to openjdk8u for parity with Oracle > 8u291. > > The original patch does not apply cleanly. > > - openjdk8u does not have arm (32-bit) port, striped arm specific > changes from the patch. > - "precond" macro is not defined in openjdk8u, replaced with assert(...). > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8248901 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.00/ The webrev above still includes two occurrences of precond. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Wed Jun 23 11:15:50 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Jun 2021 12:15:50 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> Message-ID: <5647ff68-8938-c479-a918-092d73db8a06@redhat.com> On 6/23/21 9:46 AM, Andrew Dinn wrote: > On 22/06/2021 15:20, Zhengyu Gu wrote: >> I would like to backport this patch to openjdk8u for parity with Oracle >> 8u291. Parity only really makes sense in the context of bug fixes. >> The original patch does not apply cleanly. >> >> - openjdk8u does not have arm (32-bit) port, striped arm specific >> changes from the patch. >> - "precond" macro is not defined in openjdk8u, replaced with assert(...). >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8248901 >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/ce8fb40c9174 >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.00/ > The webrev above still includes two occurrences of precond. I'm not convinced we need this backport at all. It doesn't fix any bugs, and is only used for the one-liner is_uimm12 in the fix for 8247766. This patch is harmless, but we should at least think about the churn in 8u. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 23 11:30:27 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Jun 2021 12:30:27 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <5647ff68-8938-c479-a918-092d73db8a06@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <5647ff68-8938-c479-a918-092d73db8a06@redhat.com> Message-ID: On 6/23/21 12:15 PM, Andrew Haley wrote: > I'm not convinced we need this backport at all. It doesn't fix any bugs, > and is only used for the one-liner is_uimm12 in the fix for 8247766. This > patch is harmless, but we should at least think about the churn in 8u. For avoidance of doubt, that is_uimm12(offset >> shift) could be (offset >> shift) < ((int64_t)1 << 12) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jvanek at redhat.com Wed Jun 23 11:38:59 2021 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 23 Jun 2021 13:38:59 +0200 Subject: Wno-error=format-overflow needed onnewer gccs In-Reply-To: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> References: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> Message-ID: <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> Ping please? On 6/22/21 3:56 PM, Jiri Vanek wrote: > Hello! > > For pretty long tim, on newer gcc default build fails as: > > Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parse3.cpp > /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp: In static member function ?static void os::Linux::check_signal_handler(int)?: > /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp:4999:15: error: ?%s? directive argument is null [-Werror=format-overflow=] > ?4999 |???? tty->print("Warning: %s handler ", exception_name(sig, buf, O_BUFLEN)); > ????? |???? ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parseHelper.cpp > cc1plus: all warnings being treated as errors > gmake[6]: *** [/home/jvanek/hg/jdk8u-dev/hotspot/make/linux/makefiles/rules.make:151: os_linux.o] Error 1 > > > You need to build as > make? WARNINGS_ARE_ERRORS="-Wno-error=format-overflow" > > > to make it works. I'm unabel to decide if the warning is valid. If it is, can you please fix it? > If not, I can make webrev and adding it to default set of hotspot's excluded warnings. > > J. > > > If somebody is sitting on it right now, feel free to push on you own :) > > > the above exclusion is making the jdk to build: > > make? WARNINGS_ARE_ERRORS="-Wno-error=format-overflow" > ... > > > ----- Build times ------- > Start 2021-06-22 15:49:22 > End?? 2021-06-22 15:51:05 > 00:00:00 corba > 00:00:00 hotspot > 00:00:00 jaxp > 00:00:00 jaxws > 00:01:43 jdk > 00:00:00 langtools > 00:01:43 TOTAL > ------------------------- > Finished building OpenJDK for target 'default' > > > -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From zgu at redhat.com Wed Jun 23 12:16:10 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 23 Jun 2021 08:16:10 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> Message-ID: <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> Hi Andrew, >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.00/ > The webrev above still includes two occurrences of precond. Oops, uploaded webrev from wrong machine. Updated: https://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.01/ Thanks, -Zhengyu > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From zgu at redhat.com Wed Jun 23 12:26:05 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 23 Jun 2021 08:26:05 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <5647ff68-8938-c479-a918-092d73db8a06@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <5647ff68-8938-c479-a918-092d73db8a06@redhat.com> Message-ID: Hi Andrew, On 6/23/21 7:15 AM, Andrew Haley wrote: > > I'm not convinced we need this backport at all. It doesn't fix any bugs, > and is only used for the one-liner is_uimm12 in the fix for 8247766. This > patch is harmless, but we should at least think about the churn in 8u. > Yes, I backport this as a prerequisition of JDK-8247766. Thanks, -Zhengyu From adinn at redhat.com Wed Jun 23 12:33:19 2021 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 23 Jun 2021 13:33:19 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> Message-ID: On 23/06/2021 13:16, Zhengyu Gu wrote: >>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.00/ >> The webrev above still includes two occurrences of precond. > > Oops, uploaded webrev from wrong machine. > > Updated: https://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.01/ Ok, this looks good now. Consider it reviewed. As you say this backport is needed for to enable backport of JDK-8247766. The latter does fix a bug whereas the bug that this originally fixed does not exist in jdk8u. I believe that is a good reason to backport this fix but that's not my decision to make. You will need to get agreement from an actual maintainer before you can push this. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From zgu at redhat.com Wed Jun 23 12:38:12 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 23 Jun 2021 08:38:12 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> Message-ID: <8ab02657-f7d3-670b-203b-fe6cb667be54@redhat.com> Hi Andrew, >> >> Updated: https://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.01/ > Ok, this looks good now. Consider it reviewed. > Thanks for the review. > As you say this backport is needed for to enable backport of > JDK-8247766. The latter does fix a bug whereas the bug that this > originally fixed does not exist in jdk8u. > > I believe that is a good reason to backport this fix but that's not my > decision to make. You will? need to get agreement from an actual > maintainer before you can push this. Of course, I will request an approval before push this patch. -Zhengyu > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From gnu.andrew at redhat.com Wed Jun 23 16:47:15 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Jun 2021 17:47:15 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> Message-ID: <20210623164715.GD782669@rincewind> On 08:16 Wed 23 Jun , Zhengyu Gu wrote: > Hi Andrew, > > > > > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.00/ > > The webrev above still includes two occurrences of precond. > > Oops, uploaded webrev from wrong machine. > > Updated: https://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.01/ > > Thanks, > > -Zhengyu > This seems to be missing changes that were made for 11u. With backports, we should work from the closest version that has the fix, so to try and avoid repeating analysis that has already been done in earlier reviews. For 8u, this should mean working from 11u, unless there is a good reason why the fix is not applicable there. In the 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 the precond macros are introduced from JDK-8223140, which, given their simplicity, I think makes sense and will help any future backports that use these macros. It also includes the ppc64 fix, JDK-8215144, though uncredited, and some sparc changes (there is no sparc port in trunk). If we're going to backport this to 8u, I'd like to see the backport based on 11u rather than diverging. It should also credit both JDK-8248901 and JDK-8215144 (I've fixed the missing backport bug for 11u there). Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 23 17:24:39 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Jun 2021 18:24:39 +0100 Subject: Wno-error=format-overflow needed onnewer gccs In-Reply-To: <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> References: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> Message-ID: <20210623172439.GE782669@rincewind> On 13:38 Wed 23 Jun , Jiri Vanek wrote: > Ping please? > > On 6/22/21 3:56 PM, Jiri Vanek wrote: > > Hello! > > > > For pretty long tim, on newer gcc default build fails as: > > > > Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parse3.cpp > > /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp: In static member function ?static void os::Linux::check_signal_handler(int)?: > > /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp:4999:15: error: ?%s? directive argument is null [-Werror=format-overflow=] > > ?4999 |???? tty->print("Warning: %s handler ", exception_name(sig, buf, O_BUFLEN)); > > ????? |???? ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parseHelper.cpp > > cc1plus: all warnings being treated as errors > > gmake[6]: *** [/home/jvanek/hg/jdk8u-dev/hotspot/make/linux/makefiles/rules.make:151: os_linux.o] Error 1 > > > > > > You need to build as > > make? WARNINGS_ARE_ERRORS="-Wno-error=format-overflow" > > > > > > to make it works. I'm unabel to decide if the warning is valid. If it is, can you please fix it? > > If not, I can make webrev and adding it to default set of hotspot's excluded warnings. > > > > J. > > > > > > If somebody is sitting on it right now, feel free to push on you own :) > > I've been sitting on a potential fix for some time: https://icedtea.wildebeest.org/hg/icedtea8-forest/hotspot/rev/9f2ceb42dc64 which I also picked up when trying to build with GCC 10 in Fedora. Strangely, it doesn't seem to occur on 11u or 17, which is why I've hesitated so far to take this to trunk (where the code is the same as far as I can see, though it moved to src/hotspot/os/posix/signals_posix.cpp in trunk) I'll look at filing an OpenJDK bug and fix for this. In the meantime, we could consider a critical fix for 8u302 to disable the warning. Please supply a webrev for this. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Thu Jun 24 09:48:24 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 24 Jun 2021 10:48:24 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <20210623164715.GD782669@rincewind> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> Message-ID: <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> On 23/06/2021 17:47, Andrew Hughes wrote: > This seems to be missing changes that were made for 11u. With backports, > we should work from the closest version that has the fix, so to try and > avoid repeating analysis that has already been done in earlier reviews. > For 8u, this should mean working from 11u, unless there is a good reason > why the fix is not applicable there. All that is missing is i) the arm.ad change (this port does not exist in jdk8u) ii) use of the precond macro (replaced with assert) > In the 11u changeset: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 > > the precond macros are introduced from JDK-8223140, which, given their > simplicity, I think makes sense and will help any future backports that > use these macros. I'm not sure this is clear-cut. That patch changes code in the opto compiler. While it looks like those changes would apply cleanly and correctly, backporting them just to obtain a macro equivalent to the assert used by Zhengyu's patch is a risk. Replacing the calls to precond with equivalent calls to assert is clearly a lower risk. It also does not stop JDK-8223140 from being back-ported later should need for that arise. > It also includes the ppc64 fix, JDK-8215144, though uncredited, and some > sparc changes (there is no sparc port in trunk). If the ppc patch is needed then it can be back-ported independent of this one. > If we're going to backport this to 8u, I'd like to see the backport based > on 11u rather than diverging. It should also credit both JDK-8248901 and > JDK-8215144 (I've fixed the missing backport bug for 11u there). It is based on jdk11u. It has diverged from that patch but only in order to avoid pulling in compiler changes that have not been shown to be needed. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From jvanek at redhat.com Thu Jun 24 11:58:58 2021 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 24 Jun 2021 13:58:58 +0200 Subject: Wno-error=format-overflow needed onnewer gccs In-Reply-To: <20210623172439.GE782669@rincewind> References: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> <20210623172439.GE782669@rincewind> Message-ID: On 6/23/21 7:24 PM, Andrew Hughes wrote: > On 13:38 Wed 23 Jun , Jiri Vanek wrote: >> Ping please? >> >> On 6/22/21 3:56 PM, Jiri Vanek wrote: >>> Hello! >>> >>> For pretty long tim, on newer gcc default build fails as: >>> >>> Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parse3.cpp >>> /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp: In static member function ?static void os::Linux::check_signal_handler(int)?: >>> /home/jvanek/hg/jdk8u-dev/hotspot/src/os/linux/vm/os_linux.cpp:4999:15: error: ?%s? directive argument is null [-Werror=format-overflow=] >>> ?4999 |???? tty->print("Warning: %s handler ", exception_name(sig, buf, O_BUFLEN)); >>> ????? |???? ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Compiling /home/jvanek/hg/jdk8u-dev/hotspot/src/share/vm/opto/parseHelper.cpp >>> cc1plus: all warnings being treated as errors >>> gmake[6]: *** [/home/jvanek/hg/jdk8u-dev/hotspot/make/linux/makefiles/rules.make:151: os_linux.o] Error 1 >>> >>> >>> You need to build as >>> make? WARNINGS_ARE_ERRORS="-Wno-error=format-overflow" >>> >>> >>> to make it works. I'm unabel to decide if the warning is valid. If it is, can you please fix it? >>> If not, I can make webrev and adding it to default set of hotspot's excluded warnings. >>> >>> J. >>> >>> >>> If somebody is sitting on it right now, feel free to push on you own :) >>> > > I've been sitting on a potential fix for some time: > > https://icedtea.wildebeest.org/hg/icedtea8-forest/hotspot/rev/9f2ceb42dc64 > > which I also picked up when trying to build with GCC 10 in Fedora. > > Strangely, it doesn't seem to occur on 11u or 17, which is why I've hesitated > so far to take this to trunk (where the code is the same as far as I can see, > though it moved to src/hotspot/os/posix/signals_posix.cpp in trunk) > > I'll look at filing an OpenJDK bug and fix for this. In the meantime, we could > consider a critical fix for 8u302 to disable the warning. Please supply a webrev > for this. Here you go! http://cr.openjdk.java.net/~jvanek/format-overflow.webrev.01/webrev/ TY! > > Thanks, > -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From zgu at redhat.com Thu Jun 24 12:50:13 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 24 Jun 2021 08:50:13 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> Message-ID: <697f2397-be80-dc62-c13b-42de52bf9625@redhat.com> I am echoing Andrew Dinn's point: it is not clear-cut. I am not sure it is a good idea to take already diverged 11u backport, then further diverge it into 8u. Analyising how code evolved and its dependencies, is a big part of backport process. Usually, the closest version gives shortest path, but not always. This particular 11u backport, combined 3 patches, (especially JDK-8215144, which I believe it is irrelevant to this backport and should be done in separate backport) which is going to confuse future backporter. Thanks, -Zhengyu On 6/24/21 5:48 AM, Andrew Dinn wrote: > On 23/06/2021 17:47, Andrew Hughes wrote: >> This seems to be missing changes that were made for 11u. With backports, >> we should work from the closest version that has the fix, so to try and >> avoid repeating analysis that has already been done in earlier reviews. >> For 8u, this should mean working from 11u, unless there is a good reason >> why the fix is not applicable there. > > All that is missing is > > ? i) the arm.ad change (this port does not exist in jdk8u) > ? ii) use of the precond macro (replaced with assert) > >> In the 11u changeset: >> >> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 >> >> the precond macros are introduced from JDK-8223140, which, given their >> simplicity, I think makes sense and will help any future backports that >> use these macros. > > I'm not sure this is clear-cut. That patch changes code in the opto > compiler. While it looks like those changes would apply cleanly and > correctly, backporting them just to obtain a macro equivalent to the > assert used by Zhengyu's patch is a risk. Replacing the calls to precond > with equivalent calls to assert is clearly a lower risk. It also does > not stop JDK-8223140 from being back-ported later should need for that > arise. > >> It also includes the ppc64 fix, JDK-8215144, though uncredited, and some >> sparc changes (there is no sparc port in trunk). > > If the ppc patch is needed then it can be back-ported independent of > this one. > >> If we're going to backport this to 8u, I'd like to see the backport based >> on 11u rather than diverging. It should also credit both JDK-8248901 and >> JDK-8215144 (I've fixed the missing backport bug for 11u there). > It is based on jdk11u. It has diverged from that patch but only in order > to avoid pulling in compiler changes that have not been shown to be needed. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From sgehwolf at redhat.com Fri Jun 25 09:17:21 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 25 Jun 2021 11:17:21 +0200 Subject: [8u] RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: <19774E77-4E81-4A48-8C4A-0308128A38BE@azul.com> References: <19774E77-4E81-4A48-8C4A-0308128A38BE@azul.com> Message-ID: Hi, On Thu, 2021-06-10 at 09:23 +0000, Alexey Bakhtin wrote: > Hello, > > Could you please review the backport of JDK-8241248 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 > 11u patch : https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5d4535b3a2fe > 8u patch : http://cr.openjdk.java.net/~abakhtin/8241248.8u/webrev.v0/ This looks fine. > 11u patch is not applied clean because of different source file > location. The rest is clean If only file locations changed in the patch you can consider it clean and don't need a review. Applying for backport approval via the label/fix request comment is sufficient. Thanks, Severin From gnu.andrew at redhat.com Fri Jun 25 13:54:52 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 25 Jun 2021 14:54:52 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> Message-ID: <20210625135452.GC819520@rincewind> On 10:48 Thu 24 Jun , Andrew Dinn wrote: > On 23/06/2021 17:47, Andrew Hughes wrote: > > This seems to be missing changes that were made for 11u. With backports, > > we should work from the closest version that has the fix, so to try and > > avoid repeating analysis that has already been done in earlier reviews. > > For 8u, this should mean working from 11u, unless there is a good reason > > why the fix is not applicable there. > > All that is missing is > > i) the arm.ad change (this port does not exist in jdk8u) > ii) use of the precond macro (replaced with assert) > Compared to the 11u version, there are also changes to src/hotspot/cpu/ppc/macroAssembler_ppc.cpp, src/hotspot/cpu/sparc/assembler_sparc.hpp and src/hotspot/share/utilities/debug.hpp that are absent. While I'm ok with omitting changes from the 11u backport with good reason, tt wasn't clear to me in the initial post that the 11u version had even been considered in backporting this change. > > In the 11u changeset: > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 > > > > the precond macros are introduced from JDK-8223140, which, given their > > simplicity, I think makes sense and will help any future backports that > > use these macros. > > I'm not sure this is clear-cut. That patch changes code in the opto > compiler. While it looks like those changes would apply cleanly and > correctly, backporting them just to obtain a macro equivalent to the assert > used by Zhengyu's patch is a risk. Replacing the calls to precond with > equivalent calls to assert is clearly a lower risk. It also does not stop > JDK-8223140 from being back-ported later should need for that arise. > Sorry if I was unclear here. I'm not suggesting backporting the whole of 8223140. I'm suggesting to follow 11u in adding this hunk: --- a/src/hotspot/share/utilities/debug.hpp Sat Jul 04 08:18:17 2020 +0800 +++ b/src/hotspot/share/utilities/debug.hpp Mon Jul 06 21:29:51 2020 +0200 @@ -67,6 +67,9 @@ // For backward compatibility. #define assert(p, ...) vmassert(p, __VA_ARGS__) +#define precond(p) assert(p, "precond") +#define postcond(p) assert(p, "postcond") + #ifndef ASSERT #define vmassert_status(p, status, msg) #else See: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 This should achieve the same as replacing precond with assert, but also provide precond for future backports. While I won't insist on this, I do think it odd if 8u & 11u choose different paths on this without good reason. > > It also includes the ppc64 fix, JDK-8215144, though uncredited, and some > > sparc changes (there is no sparc port in trunk). > > If the ppc patch is needed then it can be back-ported independent of this > one. > The change removes several functions altogether. It is possible to tell just by simple inspection if this will break the builds on other platforms. The following are entirely removed and not replaced: is_simm5 is_simm11 is_simm12 is_simm13 is_simm26 min_simm max_simm min_simm13 min_simm16 >From a search of the code, it appears only is_simm26, min_simm, max_simm and min_simm16 are actually safe to be completely removed in 8u. is_simm5, is_simm11, is_simm12, is_simm13 and min_simm13 are indeed all used by the SPARC assembler code, as the 11u review already identified and fixed. This is clearly not the case in trunk, as the SPARC port has been removed. It looks like the ppc64 change is unneeded in 8u, as we don't have JDK-8144019: "PPC64 C1: Introduce Client Compiler" that introduces the is_simm13 call (and, for clarity, no I'm not suggesting we backport it ;) ) However, I can't approve this, knowing it will break SPARC. So, I suggest either those functions are left untouched or (preferably) we follow 11u in localising them to the only consumer, the SPARC port. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jun 25 13:56:22 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 25 Jun 2021 14:56:22 +0100 Subject: Wno-error=format-overflow needed onnewer gccs In-Reply-To: References: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> <20210623172439.GE782669@rincewind> Message-ID: <20210625135622.GD819520@rincewind> On 13:58 Thu 24 Jun , Jiri Vanek wrote: > > Here you go! > > http://cr.openjdk.java.net/~jvanek/format-overflow.webrev.01/webrev/ > > TY! > Ah, that simple :) Do you have access to the OpenJDK bug DB? If not, I'll handle the bug creation and getting this committed. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jvanek at redhat.com Fri Jun 25 14:07:08 2021 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 25 Jun 2021 16:07:08 +0200 Subject: Wno-error=format-overflow needed onnewer gccs In-Reply-To: <20210625135622.GD819520@rincewind> References: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> <20210623172439.GE782669@rincewind> <20210625135622.GD819520@rincewind> Message-ID: Here you go: https://bugs.openjdk.java.net/browse/JDK-8269388 I'm not sure how to set it to jdk8 On 6/25/21 3:56 PM, Andrew Hughes wrote: > On 13:58 Thu 24 Jun , Jiri Vanek wrote: >> >> Here you go! >> >> http://cr.openjdk.java.net/~jvanek/format-overflow.webrev.01/webrev/ >> >> TY! >> > > Ah, that simple :) > > Do you have access to the OpenJDK bug DB? If not, I'll handle the bug > creation and getting this committed. > > Thanks, > -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From gnu.andrew at redhat.com Fri Jun 25 14:16:59 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 25 Jun 2021 15:16:59 +0100 Subject: Wno-error=format-overflow needed onnewer gccs In-Reply-To: References: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> <20210623172439.GE782669@rincewind> <20210625135622.GD819520@rincewind> Message-ID: <20210625141659.GE819520@rincewind> On 16:07 Fri 25 Jun , Jiri Vanek wrote: > Here you go: > https://bugs.openjdk.java.net/browse/JDK-8269388 > > I'm not sure how to set it to jdk8 > 'openjdk8u' in Affects Version is probably best, so as to restrict it to just OpenJDK and not Oracle's fork. I added labels to make it clear this isn't needed for later versions. I'll push it on your behalf before we freeze 8u. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Fri Jun 25 14:47:23 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 25 Jun 2021 15:47:23 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <20210625135452.GC819520@rincewind> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> Message-ID: <5397897a-27b1-7d1d-1412-538aa3cf4474@redhat.com> On 25/06/2021 14:54, Andrew Hughes wrote: > Sorry if I was unclear here. I'm not suggesting backporting the whole > of 8223140. I'm suggesting to follow 11u in adding this hunk: > > --- a/src/hotspot/share/utilities/debug.hpp Sat Jul 04 08:18:17 2020 +0800 > +++ b/src/hotspot/share/utilities/debug.hpp Mon Jul 06 21:29:51 2020 +0200 > @@ -67,6 +67,9 @@ > // For backward compatibility. > #define assert(p, ...) vmassert(p, __VA_ARGS__) > > +#define precond(p) assert(p, "precond") > +#define postcond(p) assert(p, "postcond") > + > #ifndef ASSERT > #define vmassert_status(p, status, msg) > #else > > See: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 > > This should achieve the same as replacing precond with assert, but also provide > precond for future backports. I'm happy for that specific change to be included given that it was included in jdk11u. However, cherry-picking bits of one patch and placing them in another patch seems like an anti-pattern to me. > From a search of the code, it appears only is_simm26, min_simm, max_simm > and min_simm16 are actually safe to be completely removed in 8u. > > is_simm5, is_simm11, is_simm12, is_simm13 and min_simm13 are indeed all > used by the SPARC assembler code, as the 11u review already identified and > fixed. This is clearly not the case in trunk, as the SPARC port has been > removed. Oh, indeed, that's my error. I did look at the jdk11u change set but then I completely forgot we needed the SPARC changes when I reviewed Zhengyu's patch. > However, I can't approve this, knowing it will break SPARC. So, I > suggest either those functions are left untouched or (preferably) we > follow 11u in localising them to the only consumer, the SPARC port. Yes, I think the patch should be updated to include the jdk11u additions to the SPARC assembler. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From zgu at redhat.com Fri Jun 25 15:05:56 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 25 Jun 2021 11:05:56 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <20210625135452.GC819520@rincewind> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> Message-ID: <1185389c-28cd-e74d-4833-d4998db410a2@redhat.com> I redo 8u patch, now, it is based on jdk11u patch. As Andrew Hughes mentioned, the original patch misses SPARC changes, that can break SPARC build. After removing arm and PPC specific changes, the only conflict is the placement of "precond" macro in debug.hpp. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.02/ Thanks, -Zhengyu On 6/25/21 9:54 AM, Andrew Hughes wrote: > On 10:48 Thu 24 Jun , Andrew Dinn wrote: >> On 23/06/2021 17:47, Andrew Hughes wrote: >>> This seems to be missing changes that were made for 11u. With backports, >>> we should work from the closest version that has the fix, so to try and >>> avoid repeating analysis that has already been done in earlier reviews. >>> For 8u, this should mean working from 11u, unless there is a good reason >>> why the fix is not applicable there. >> >> All that is missing is >> >> i) the arm.ad change (this port does not exist in jdk8u) >> ii) use of the precond macro (replaced with assert) >> > > Compared to the 11u version, there are also changes to > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp, > src/hotspot/cpu/sparc/assembler_sparc.hpp and > src/hotspot/share/utilities/debug.hpp that are absent. > > While I'm ok with omitting changes from the 11u backport with good reason, > tt wasn't clear to me in the initial post that the 11u version had even > been considered in backporting this change. > >>> In the 11u changeset: >>> >>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 >>> >>> the precond macros are introduced from JDK-8223140, which, given their >>> simplicity, I think makes sense and will help any future backports that >>> use these macros. >> >> I'm not sure this is clear-cut. That patch changes code in the opto >> compiler. While it looks like those changes would apply cleanly and >> correctly, backporting them just to obtain a macro equivalent to the assert >> used by Zhengyu's patch is a risk. Replacing the calls to precond with >> equivalent calls to assert is clearly a lower risk. It also does not stop >> JDK-8223140 from being back-ported later should need for that arise. >> > > Sorry if I was unclear here. I'm not suggesting backporting the whole > of 8223140. I'm suggesting to follow 11u in adding this hunk: > > --- a/src/hotspot/share/utilities/debug.hpp Sat Jul 04 08:18:17 2020 +0800 > +++ b/src/hotspot/share/utilities/debug.hpp Mon Jul 06 21:29:51 2020 +0200 > @@ -67,6 +67,9 @@ > // For backward compatibility. > #define assert(p, ...) vmassert(p, __VA_ARGS__) > > +#define precond(p) assert(p, "precond") > +#define postcond(p) assert(p, "postcond") > + > #ifndef ASSERT > #define vmassert_status(p, status, msg) > #else > > See: > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 > > This should achieve the same as replacing precond with assert, but also provide > precond for future backports. > > While I won't insist on this, I do think it odd if 8u & 11u choose different > paths on this without good reason. > >>> It also includes the ppc64 fix, JDK-8215144, though uncredited, and some >>> sparc changes (there is no sparc port in trunk). >> >> If the ppc patch is needed then it can be back-ported independent of this >> one. >> > > The change removes several functions altogether. It is possible to tell just > by simple inspection if this will break the builds on other platforms. > > The following are entirely removed and not replaced: > > is_simm5 > is_simm11 > is_simm12 > is_simm13 > is_simm26 > min_simm > max_simm > min_simm13 > min_simm16 > > From a search of the code, it appears only is_simm26, min_simm, max_simm > and min_simm16 are actually safe to be completely removed in 8u. > > is_simm5, is_simm11, is_simm12, is_simm13 and min_simm13 are indeed all > used by the SPARC assembler code, as the 11u review already identified and > fixed. This is clearly not the case in trunk, as the SPARC port has been > removed. > > It looks like the ppc64 change is unneeded in 8u, as we don't have > JDK-8144019: "PPC64 C1: Introduce Client Compiler" that introduces the > is_simm13 call (and, for clarity, no I'm not suggesting we backport it ;) ) > > However, I can't approve this, knowing it will break SPARC. So, I > suggest either those functions are left untouched or (preferably) we > follow 11u in localising them to the only consumer, the SPARC port. > > Thanks, > From gnu.andrew at redhat.com Fri Jun 25 15:42:42 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 25 Jun 2021 16:42:42 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <5397897a-27b1-7d1d-1412-538aa3cf4474@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> <5397897a-27b1-7d1d-1412-538aa3cf4474@redhat.com> Message-ID: <20210625154242.GF819520@rincewind> On 15:47 Fri 25 Jun , Andrew Dinn wrote: > On 25/06/2021 14:54, Andrew Hughes wrote: > > Sorry if I was unclear here. I'm not suggesting backporting the whole > > of 8223140. I'm suggesting to follow 11u in adding this hunk: > > > > --- a/src/hotspot/share/utilities/debug.hpp Sat Jul 04 08:18:17 2020 +0800 > > +++ b/src/hotspot/share/utilities/debug.hpp Mon Jul 06 21:29:51 2020 +0200 > > @@ -67,6 +67,9 @@ > > // For backward compatibility. > > #define assert(p, ...) vmassert(p, __VA_ARGS__) > > +#define precond(p) assert(p, "precond") > > +#define postcond(p) assert(p, "postcond") > > + > > #ifndef ASSERT > > #define vmassert_status(p, status, msg) > > #else > > > > See: > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d21f0f95e6b4 > > > > This should achieve the same as replacing precond with assert, but also provide > > precond for future backports. > > I'm happy for that specific change to be included given that it was included > in jdk11u. However, cherry-picking bits of one patch and placing them in > another patch seems like an anti-pattern to me. > I agree. It's not something I'm a fan of either. However, in cases like this, where it's a generic helper function that is only part of the original patch because that's where someone first thought to use it, I think it's legitimate to make the backport that first uses it be the one that introduces it in 8u. I agree with you that backporting a patch just for such a macro would be unacceptable. The only other alternative is to replace the offending code in the backport. The best path to choose pretty much depends on the scale of the change in question. With a couple of one-liner macros like this, I definitely think just including them in the backport is the best long-term option. > > From a search of the code, it appears only is_simm26, min_simm, max_simm > > and min_simm16 are actually safe to be completely removed in 8u. > > > > is_simm5, is_simm11, is_simm12, is_simm13 and min_simm13 are indeed all > > used by the SPARC assembler code, as the 11u review already identified and > > fixed. This is clearly not the case in trunk, as the SPARC port has been > > removed. > > Oh, indeed, that's my error. I did look at the jdk11u change set but then I > completely forgot we needed the SPARC changes when I reviewed Zhengyu's > patch. > > > However, I can't approve this, knowing it will break SPARC. So, I > > suggest either those functions are left untouched or (preferably) we > > follow 11u in localising them to the only consumer, the SPARC port. > Yes, I think the patch should be updated to include the jdk11u additions to > the SPARC assembler. > I likely would not have spotted it myself, were it not for me doing what I always tend to do with backports and comparing it with the 11u version. I believe our role as maintainers is not to contradict the expert domain knowledge of reviewers like yourself, but to complement it from the perspective of 8u as a whole, looking at the stability of including the patch and the backporting decisions in the context of past and potential future backports. It is with that mind in that I questioned why the 11u differences were not mentioned in the original review. I guess the general lesson from this is we should be very wary of any backports that remove functions, because that can only be guaranteed safe in the original context and needs to be reanalysed when applied to a different codebase. Regards, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jun 25 15:54:04 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 25 Jun 2021 16:54:04 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <1185389c-28cd-e74d-4833-d4998db410a2@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> <1185389c-28cd-e74d-4833-d4998db410a2@redhat.com> Message-ID: <20210625155404.GG819520@rincewind> On 11:05 Fri 25 Jun , Zhengyu Gu wrote: > I redo 8u patch, now, it is based on jdk11u patch. > > As Andrew Hughes mentioned, the original patch misses SPARC changes, that > can break SPARC build. > > After removing arm and PPC specific changes, the only conflict is the > placement of "precond" macro in debug.hpp. > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.02/ > > > Thanks, > > -Zhengyu > Thanks. This looks good to me now. I'll approve once Andrew Dinn gives it the thumbs up. -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From zgu at redhat.com Fri Jun 25 16:15:14 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 25 Jun 2021 12:15:14 -0400 Subject: [8u] RFR 8129940: JRadioButton does not honor non-standard FocusTraversalKeys Message-ID: <6ecf2a51-0c44-39ce-15c3-9f924b68966e@redhat.com> I would like to backport this patch to openjdk8u for parity with Oracle 8u311. The original bug: https://bugs.openjdk.java.net/browse/JDK-8129940 The original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fbf897c33625 8u patch: http://cr.openjdk.java.net/~zgu/JDK-8129940-8u/webrev.00/ The jdk9 patch does not apply cleanly, but only conflict is copyright year of BasicRadioButtonUI.java file. Test: Included FocusTraversal/FocusTraversal.java test fails without patch and passes with it on Linux x86_64 Thanks, -Zhengyu From zgu at redhat.com Fri Jun 25 19:58:46 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 25 Jun 2021 15:58:46 -0400 Subject: [8u] RFR 8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime Message-ID: <3ce35cd5-a4a4-77e6-7d8e-4c8b2d2935a7@redhat.com> I would like to backport this patch to openjdk8u for parity with Oracle 8u301. Bug: https://bugs.openjdk.java.net/browse/JDK-8004148 Patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/29b0423db43c The original patch does not apply cleanly, due to different context, can be easily resolved manually. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8004148-8u/webrev.00/ Thanks, -Zhengyu From kalinshi at tencent.com Mon Jun 28 05:46:43 2021 From: kalinshi at tencent.com (=?gb2312?B?a2FsaW5zaGkoyqm72yk=?=) Date: Mon, 28 Jun 2021 05:46:43 +0000 Subject: [8u] RFR 8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M Message-ID: Please help review JDK-8264752 backport to jdk8u-dev. This PR is already backported to jdk11u. The original patch does not apply cleanly, conflicts are: - ClassFileInstaller doesn't need full name in TestBadOptionValues.java (same conflict in jdk11u) - Change "log_error(arguments)" to "tty->print_cr" in JfrOptionSet::adjust_memory_options Original bug: https://bugs.openjdk.java.net/browse/JDK-8264752 Original patch: https://git.openjdk.java.net/jdk/commit/377b3461 8u webrev: crosses hotspot and jdk repository http://cr.openjdk.java.net/~hshi/8264752/webrev_total/ Test: jdk_jfr with fastdebug/release build pass Regards Hui From gnu.andrew at redhat.com Mon Jun 28 05:56:43 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Jun 2021 06:56:43 +0100 Subject: OpenJDK 8u302-b06 EA Released Message-ID: <20210628055643.GA1258169@rincewind> I've made available an early access source bundle for 8u302, based on the tag jdk8u302-b06: https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b06-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b06-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint =3D CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 2cf0631e7d8638da8d44fae518eee918e38cc48af7acb22e48a87affdeccf8cf openjdk8u302-b06-ea.tar.xz 7552ded488755eb52944e53acec97880a6a224e91e725e07e137de00bf4ca709 openjdk8u302-b06-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u302-b06-ea.sha256 Changes in 8u302-b06: - JDK-8267545: [8u] Enable Xcode 12 builds on macOS - JDK-8268444: keytool -v -list print is incorrect after backport JDK-8141457 Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jun 28 05:58:27 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Jun 2021 06:58:27 +0100 Subject: [FREEZE] 8u302 NOW FROZEN Message-ID: <20210628055827.GA1258599@rincewind> The release forest: https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) is now frozen in preparation for release on 2021-07-20. I will push the final pre-release tag, jdk8u302-b07, once testing completes. The final release tag will be no lower than jdk8u302-b08. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jun 28 06:29:28 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Jun 2021 07:29:28 +0100 Subject: Wno-error=format-overflow needed onnewer gccs In-Reply-To: References: <1297898b-ceb7-fcde-2d0e-f52b19b23b1a@redhat.com> <884d64b7-d6c2-cc29-7384-8396cf010e46@redhat.com> <20210623172439.GE782669@rincewind> <20210625135622.GD819520@rincewind> Message-ID: <20210628062928.GA1270336@rincewind> On 16:07 Fri 25 Jun , Jiri Vanek wrote: > Here you go: > https://bugs.openjdk.java.net/browse/JDK-8269388 > > I'm not sure how to set it to jdk8 > Seeing a build failure with this on older GCCs: https://bugs.openjdk.java.net/browse/JDK-8269468 -Wformat-overflow seems to have only been introduced in GCC 7. Testing a fix now, which we'll need to approve to unbreak the build. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Mon Jun 28 09:29:39 2021 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 28 Jun 2021 10:29:39 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <20210625155404.GG819520@rincewind> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> <1185389c-28cd-e74d-4833-d4998db410a2@redhat.com> <20210625155404.GG819520@rincewind> Message-ID: <141739f8-f786-e419-7b49-76df3f2cc81f@redhat.com> On 25/06/2021 16:54, Andrew Hughes wrote: > Thanks. This looks good to me now. > > I'll approve once Andrew Dinn gives it the thumbs up. Consider that given. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From gnu.andrew at redhat.com Mon Jun 28 13:36:56 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Jun 2021 14:36:56 +0100 Subject: [8u] RFR: JDK-8269468: JDK-8269388 breaks the build on older GCCs Message-ID: <20210628133656.GA1305358@rincewind> Bug: https://bugs.openjdk.java.net/browse/JDK-8269468 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8269468/webrev.01/ In trying to promote 8u302-b07, I found the addition of -Werror=format-overflow broke the build on older GCCs (specifically building on RHEL 7). The option is fairly new, only introduced in GCC 7: https://gcc.gnu.org/gcc-7/changes.html Adding a version conditional similar to others in that file fixes the build. A quick review and critical-ack of this would be appreciated so we can promote 8u302-b07. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Mon Jun 28 14:19:00 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 28 Jun 2021 16:19:00 +0200 Subject: [8u] RFR: JDK-8269468: JDK-8269388 breaks the build on older GCCs In-Reply-To: <20210628133656.GA1305358@rincewind> References: <20210628133656.GA1305358@rincewind> Message-ID: <0e5d52bf59e399dfdf1cb2a38d23cf8dabaa91d9.camel@redhat.com> On Mon, 2021-06-28 at 14:36 +0100, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8269468 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8269468/webrev.01/ This looks fine. > In trying to promote 8u302-b07, I found the addition of -Werror=format-overflow > broke the build on older GCCs (specifically building on RHEL 7). > > The option is fairly new, only introduced in GCC 7: > > https://gcc.gnu.org/gcc-7/changes.html > > Adding a version conditional similar to others in that file fixes the > build. OK. Aside: GCC 11, which I have here, prints this for -dumpversion: '11'. That is, CC_VER_MINOR is incorrect. As this patch isn't using that variable, it's fine. However a bug nevertheless. $ gcc -dumpfullversion 11.1.1 $ gcc -dumpversion 11 $ CC_VER_MINOR=$(gcc -dumpversion | sed 's/egcs-//' | cut -d'.' -f2); CC_VER_MAJOR=$(gcc -dumpversion | sed 's/egcs-//' | cut -d'.' -f1); echo $CC_VER_MAJOR.$CC_VER_MINOR 11.11 Thanks, Severin From aph at redhat.com Mon Jun 28 14:19:37 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Jun 2021 15:19:37 +0100 Subject: [8u] RFR: JDK-8269468: JDK-8269388 breaks the build on older GCCs In-Reply-To: <20210628133656.GA1305358@rincewind> References: <20210628133656.GA1305358@rincewind> Message-ID: On 6/28/21 2:36 PM, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8269468 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8269468/webrev.01/ > > In trying to promote 8u302-b07, I found the addition of -Werror=format-overflow > broke the build on older GCCs (specifically building on RHEL 7). > > The option is fairly new, only introduced in GCC 7: > > https://gcc.gnu.org/gcc-7/changes.html > > Adding a version conditional similar to others in that file fixes the > build. > > A quick review and critical-ack of this would be appreciated so we > can promote 8u302-b07. I will do that if you like, but wouldn't this be better as an autoconf check FLAGS_CXX_COMPILER_CHECK_ARGUMENTS ? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Jun 28 14:59:07 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 28 Jun 2021 14:59:07 +0000 Subject: [8u] RFR 8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime Message-ID: <2EC5CB72-B458-4E9A-B7CF-15F84C7ADBEA@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Zhengyu Gu Date: Friday, June 25, 2021 at 1:01 PM To: jdk8u-dev Subject: [8u] RFR 8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime I would like to backport this patch to openjdk8u for parity with Oracle 8u301. Bug: https://bugs.openjdk.java.net/browse/JDK-8004148 Patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/29b0423db43c The original patch does not apply cleanly, due to different context, can be easily resolved manually. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8004148-8u/webrev.00/ Thanks, -Zhengyu From gnu.andrew at redhat.com Mon Jun 28 15:11:53 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Jun 2021 16:11:53 +0100 Subject: [8u] RFR: JDK-8269468: JDK-8269388 breaks the build on older GCCs In-Reply-To: <0e5d52bf59e399dfdf1cb2a38d23cf8dabaa91d9.camel@redhat.com> References: <20210628133656.GA1305358@rincewind> <0e5d52bf59e399dfdf1cb2a38d23cf8dabaa91d9.camel@redhat.com> Message-ID: <20210628151153.GA1306550@rincewind> On 16:19 Mon 28 Jun , Severin Gehwolf wrote: > On Mon, 2021-06-28 at 14:36 +0100, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8269468 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8269468/webrev.01/ > > This looks fine. > > > In trying to promote 8u302-b07, I found the addition of -Werror=format-overflow > > broke the build on older GCCs (specifically building on RHEL 7). > > > > The option is fairly new, only introduced in GCC 7: > > > > https://gcc.gnu.org/gcc-7/changes.html > > > > Adding a version conditional similar to others in that file fixes the > > build. > > OK. > Thanks. I'll flag as jdk8u-critical-request. > Aside: > > GCC 11, which I have here, prints this for -dumpversion: '11'. That is, > CC_VER_MINOR is incorrect. As this patch isn't using that variable, > it's fine. However a bug nevertheless. > > $ gcc -dumpfullversion > 11.1.1 > $ gcc -dumpversion > 11 > $ CC_VER_MINOR=$(gcc -dumpversion | sed 's/egcs-//' | cut -d'.' -f2); CC_VER_MAJOR=$(gcc -dumpversion | sed 's/egcs-//' | cut -d'.' -f1); echo $CC_VER_MAJOR.$CC_VER_MINOR > 11.11 > Same here with 8. >From the other tests, I would guess the logic dates back to when GCC made more use of the minor version numbers. It seems like gcc -dumpfullversion would fix it, but that doesn't exist on older GCCs: $ cat /etc/redhat-release Red Hat Enterprise Linux Workstation release 6.10 (Santiago) $ cc -dumpversion 4.4.7 $ echo $? 4 $ cc -dumpfullversion cc: no input files $ echo $? 1 $ cat /etc/redhat-release Red Hat Enterprise Linux Client release 7.9 (Maipo) $ cc -dumpversion 4.8.5 $ echo $? 0 $ cc -dumpfullversion cc: fatal error: no input files compilation terminated. $ echo $? 4 $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.3 (Ootpa) $ gcc -dumpversion 8 $ echo $? 0 $ gcc -dumpfullversion 8.3.1 $ echo $? 0 so it would need to be fallback on gcc -dumpversion. > Thanks, > Severin > -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hohensee at amazon.com Mon Jun 28 15:19:07 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 28 Jun 2021 15:19:07 +0000 Subject: [8u] RFR 8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M Message-ID: <1F68266B-196E-4574-A71C-F56E7265BDF6@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of "kalinshi(??)" Date: Sunday, June 27, 2021 at 10:47 PM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR 8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M Please help review JDK-8264752 backport to jdk8u-dev. This PR is already backported to jdk11u. The original patch does not apply cleanly, conflicts are: - ClassFileInstaller doesn't need full name in TestBadOptionValues.java (same conflict in jdk11u) - Change "log_error(arguments)" to "tty->print_cr" in JfrOptionSet::adjust_memory_options Original bug: https://bugs.openjdk.java.net/browse/JDK-8264752 Original patch: https://git.openjdk.java.net/jdk/commit/377b3461 8u webrev: crosses hotspot and jdk repository http://cr.openjdk.java.net/~hshi/8264752/webrev_total/ Test: jdk_jfr with fastdebug/release build pass Regards Hui From zgu at redhat.com Mon Jun 28 16:20:08 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 28 Jun 2021 12:20:08 -0400 Subject: [8u] RFR 8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime In-Reply-To: <2EC5CB72-B458-4E9A-B7CF-15F84C7ADBEA@amazon.com> References: <2EC5CB72-B458-4E9A-B7CF-15F84C7ADBEA@amazon.com> Message-ID: <52d4ba2f-50f6-f29b-e135-c309090a6fde@redhat.com> Thanks, Paul. Tagged for approval. -Zhengyu On 6/28/21 10:59 AM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Friday, June 25, 2021 at 1:01 PM > To: jdk8u-dev > Subject: [8u] RFR 8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime > > I would like to backport this patch to openjdk8u for parity with Oracle > 8u301. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8004148 > Patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/29b0423db43c > > The original patch does not apply cleanly, due to different context, can > be easily resolved manually. > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8004148-8u/webrev.00/ > > Thanks, > > -Zhengyu > > From gnu.andrew at redhat.com Mon Jun 28 16:58:39 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Jun 2021 17:58:39 +0100 Subject: [8u] RFR: JDK-8269468: JDK-8269388 breaks the build on older GCCs In-Reply-To: References: <20210628133656.GA1305358@rincewind> Message-ID: <20210628165839.GB1306550@rincewind> On 15:19 Mon 28 Jun , Andrew Haley wrote: > On 6/28/21 2:36 PM, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8269468 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8269468/webrev.01/ > > > > In trying to promote 8u302-b07, I found the addition of -Werror=format-overflow > > broke the build on older GCCs (specifically building on RHEL 7). > > > > The option is fairly new, only introduced in GCC 7: > > > > https://gcc.gnu.org/gcc-7/changes.html > > > > Adding a version conditional similar to others in that file fixes the > > build. > > > > A quick review and critical-ack of this would be appreciated so we > > can promote 8u302-b07. > > I will do that if you like, but wouldn't this be better as an autoconf check > FLAGS_CXX_COMPILER_CHECK_ARGUMENTS ? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > Good point. A compiler check rather than a version test would be better. I'd forgotten we had both ways in 8u, as it still has the old HotSpot build with lots of version tests. This is my revised version: https://cr.openjdk.java.net/~andrew/openjdk8/8269468/webrev.02/ It works fine locally with GCC 8: checking if the C compiler supports "-Wformat-overflow -Werror"... yes checking if the C++ compiler supports "-Wformat-overflow -Werror"... yes checking if both compilers support "-Wformat-overflow -Werror"... yes and on RHEL 7 with GCC 4: checking if the C compiler supports "-Wformat-overflow -Werror"... no checking if the C++ compiler supports "-Wformat-overflow -Werror"... no checking if both compilers support "-Wformat-overflow -Werror"... no with both compiling os_linux.o. I also included a fix for this bad line which was introduced by JDK-8267545: if test "x$TOOLCHAIN_TYPE" = xgcc -o test "x$TOOLCHAIN_TYPE" = xclang; then The rogue second 'test' causes test to fail: checking if the C compiler supports "-m64"... /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.302.b07-0.0.ea.el7_9.x86_64/jdk8u302-b07/common/autoconf/generated-configure.sh: line 42635: test: too many arguments yes I thought at first my changes had caused this, but couldn't see how any of them would. Turns out it was already in the build from yesterday as well. I can stick that under a separate bug if really necessary, but as it is also local to 8u, we may as well just fix it here. Thanks, -- Andrew :) Pronouns: he / him or they / them Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Mon Jun 28 17:01:14 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Jun 2021 18:01:14 +0100 Subject: [8u] RFR: JDK-8269468: JDK-8269388 breaks the build on older GCCs In-Reply-To: <20210628165839.GB1306550@rincewind> References: <20210628133656.GA1305358@rincewind> <20210628165839.GB1306550@rincewind> Message-ID: <16672455-c7ad-c0c8-71c9-6ca4f3431fcc@redhat.com> On 6/28/21 5:58 PM, Andrew Hughes wrote: > Good point. A compiler check rather than a version test would be better. > I'd forgotten we had both ways in 8u, as it still has the old HotSpot build > with lots of version tests. > > This is my revised version: > > https://cr.openjdk.java.net/~andrew/openjdk8/8269468/webrev.02/ > > It works fine locally with GCC 8: > > checking if the C compiler supports "-Wformat-overflow -Werror"... yes > checking if the C++ compiler supports "-Wformat-overflow -Werror"... yes > checking if both compilers support "-Wformat-overflow -Werror"... yes > > and on RHEL 7 with GCC 4: > > checking if the C compiler supports "-Wformat-overflow -Werror"... no > checking if the C++ compiler supports "-Wformat-overflow -Werror"... no > checking if both compilers support "-Wformat-overflow -Werror"... no > > with both compiling os_linux.o. Perfect, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kalinshi at tencent.com Tue Jun 29 02:23:48 2021 From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=) Date: Tue, 29 Jun 2021 02:23:48 +0000 Subject: =?utf-8?B?5Zue5aSNOiBbOHVdIFJGUiA4MjY0NzUyOiBTSUdGUEUgY3Jhc2ggd2l0aCBv?= =?utf-8?B?cHRpb24gRmxpZ2h0UmVjb3JkZXJPcHRpb25zOnRocmVhZGJ1ZmZlcnNpemU9?= =?utf-8?Q?30M?= In-Reply-To: <1F68266B-196E-4574-A71C-F56E7265BDF6@amazon.com> References: <1F68266B-196E-4574-A71C-F56E7265BDF6@amazon.com> Message-ID: Thanks Paul? Regards Hui -----????----- ???: Hohensee, Paul ????: 2021?6?28? 23:19 ???: kalinshi(??) ; jdk8u-dev at openjdk.java.net ??: [Internet]Re: [8u] RFR 8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of "kalinshi(??)" Date: Sunday, June 27, 2021 at 10:47 PM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR 8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M Please help review JDK-8264752 backport to jdk8u-dev. This PR is already backported to jdk11u. The original patch does not apply cleanly, conflicts are: - ClassFileInstaller doesn't need full name in TestBadOptionValues.java (same conflict in jdk11u) - Change "log_error(arguments)" to "tty->print_cr" in JfrOptionSet::adjust_memory_options Original bug: https://bugs.openjdk.java.net/browse/JDK-8264752 Original patch: https://git.openjdk.java.net/jdk/commit/377b3461 8u webrev: crosses hotspot and jdk repository http://cr.openjdk.java.net/~hshi/8264752/webrev_total/ Test: jdk_jfr with fastdebug/release build pass Regards Hui From Alan.Hayward at arm.com Tue Jun 29 09:32:41 2021 From: Alan.Hayward at arm.com (Alan Hayward) Date: Tue, 29 Jun 2021 09:32:41 +0000 Subject: [8u] RFR 8266749: AArch64: Backtracing broken on PAC enabled systems Message-ID: Hi, I?d like to backport this fix. Webrev: http://cr.openjdk.java.net/~ahayward/8266749/webrev/ On fedora 33 (and onwards), openJDK is build with PAC enabled on Aarch64. This patch is required to make the backtracking work. Tested manually on Fedora 33 on a PAC system (VM on M1 Mac) Applied cleanly from TIP version, except for * Files moved into VM directories * New Windows and Mac files removed from patch. I also have an 11u version awaiting review here: https://github.com/openjdk/jdk11u-dev/pull/39 (First time using webrev and back porting, so apologies if I?ve missed something) Thanks, Alan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From zgu at redhat.com Tue Jun 29 16:36:25 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 29 Jun 2021 12:36:25 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <20210625155404.GG819520@rincewind> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> <1185389c-28cd-e74d-4833-d4998db410a2@redhat.com> <20210625155404.GG819520@rincewind> Message-ID: <03c8b22e-dabf-5916-b47a-0c87b9900344@redhat.com> Hi Andrew, Are you okay with this version? Thanks, -Zhengyu On 6/25/21 11:54 AM, Andrew Hughes wrote: > On 11:05 Fri 25 Jun , Zhengyu Gu wrote: >> I redo 8u patch, now, it is based on jdk11u patch. >> >> As Andrew Hughes mentioned, the original patch misses SPARC changes, that >> can break SPARC build. >> >> After removing arm and PPC specific changes, the only conflict is the >> placement of "precond" macro in debug.hpp. >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8248901-8u/webrev.02/ >> >> >> Thanks, >> >> -Zhengyu >> > > Thanks. This looks good to me now. > > I'll approve once Andrew Dinn gives it the thumbs up. > From adinn at redhat.com Tue Jun 29 19:14:30 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 29 Jun 2021 20:14:30 +0100 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <03c8b22e-dabf-5916-b47a-0c87b9900344@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> <1185389c-28cd-e74d-4833-d4998db410a2@redhat.com> <20210625155404.GG819520@rincewind> <03c8b22e-dabf-5916-b47a-0c87b9900344@redhat.com> Message-ID: <779f1fb0-9e88-0eee-0a8c-507d8a18e347@redhat.com> On 29/06/2021 17:36, Zhengyu Gu wrote: > Are you okay with this version? Indeed. I said so in my previous post. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From zgu at redhat.com Tue Jun 29 19:15:36 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 29 Jun 2021 15:15:36 -0400 Subject: [8u] RFR 8248901: Signed immediate support in .../share/assembler.hpp is broken. In-Reply-To: <779f1fb0-9e88-0eee-0a8c-507d8a18e347@redhat.com> References: <41a164dc-ceb5-185f-144a-8c11c554a33d@redhat.com> <854ddc5c-b85e-2de7-2ce9-ca054d9bf86c@redhat.com> <20210623164715.GD782669@rincewind> <895efecd-1dda-8053-ab4e-d15f58a2be81@redhat.com> <20210625135452.GC819520@rincewind> <1185389c-28cd-e74d-4833-d4998db410a2@redhat.com> <20210625155404.GG819520@rincewind> <03c8b22e-dabf-5916-b47a-0c87b9900344@redhat.com> <779f1fb0-9e88-0eee-0a8c-507d8a18e347@redhat.com> Message-ID: Thanks, Andrew. -Zhengyu On 6/29/21 3:14 PM, Andrew Dinn wrote: > On 29/06/2021 17:36, Zhengyu Gu wrote: >> Are you okay with this version? > Indeed. I said so in my previous post. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From quantum6 at yeah.net Wed Jun 30 13:43:00 2021 From: quantum6 at yeah.net (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Wed, 30 Jun 2021 21:43:00 +0800 (CST) Subject: Remove some compiling warning, please check it Message-ID: <76b39ac4.17b1.17a5d289df8.Coremail.quantum6@yeah.net> Hello all: I compile OpenJDK8 many times. I found some commen errors would be warned. the attach files is modified. Please check it. Thanks. Best regards. Quantum Liu. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AttachOperationFailedException.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JapaneseEra.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SSLSessionContext.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AbstractJSObject.java URL: From kiriyama.takuya at fujitsu.com Thu Jun 10 08:50:28 2021 From: kiriyama.takuya at fujitsu.com (kiriyama.takuya at fujitsu.com) Date: Thu, 10 Jun 2021 08:50:28 -0000 Subject: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status may cause application dead loop In-Reply-To: <20210609035732.GB26136@rincewind> References: <20210609035732.GB26136@rincewind> Message-ID: Hi Andrew, Thank you for your reply. > Please post the patch for review and I can handle the JBS side for you. Please consider the following code: diff -r -u a/src/share/classes/sun/security/ssl/Ciphertext.java b/src/share/classes/sun/security/ssl/Ciphertext.java --- a/src/share/classes/sun/security/ssl/Ciphertext.java 2021-06-09 21:26:26.762180800 +0900 +++ b/src/share/classes/sun/security/ssl/Ciphertext.java 2021-06-10 09:00:33.660574600 +0900 @@ -31,7 +31,6 @@ * Ciphertext */ final class Ciphertext { - static final Ciphertext CIPHERTEXT_NULL = new Ciphertext(); final byte contentType; final byte handshakeType; diff -r -u a/src/share/classes/sun/security/ssl/SSLEngineImpl.java b/src/share/classes/sun/security/ssl/SSLEngineImpl.java --- a/src/share/classes/sun/security/ssl/SSLEngineImpl.java 2021-06-09 21:26:26.763148800 +0900 +++ b/src/share/classes/sun/security/ssl/SSLEngineImpl.java 2021-06-10 09:19:42.665488000 +0900 @@ -227,6 +227,19 @@ hsStatus = ciphertext.handshakeStatus; } else { hsStatus = getHandshakeStatus(); + if (ciphertext == null && !conContext.isNegotiated && + conContext.isInboundClosed() && + hsStatus == HandshakeStatus.NEED_WRAP) { + // Even the outboud is open, no futher data could be wrapped as: + // 1. the outbound is empty + // 2. no negotiated connection + // 3. the inbound has closed, cannot complete the handshake + // + // Mark the engine as closed if the handshake status is + // NEED_WRAP. Otherwise, it could lead to dead loops in + // applications. + status = Status.CLOSED; + } } int deltaSrcs = srcsRemains; @@ -258,7 +271,7 @@ } if (ciphertext == null) { - return Ciphertext.CIPHERTEXT_NULL; + return null; } // Is the handshake completed? diff -r -u a/src/share/classes/sun/security/ssl/TransportContext.java b/src/share/classes/sun/security/ssl/TransportContext.java --- a/src/share/classes/sun/security/ssl/TransportContext.java 2021-06-09 21:26:26.766062300 +0900 +++ b/src/share/classes/sun/security/ssl/TransportContext.java 2021-06-10 09:14:04.842253500 +0900 @@ -577,13 +577,7 @@ // Special case that the inbound was closed, but outbound open. return HandshakeStatus.NEED_WRAP; } - } else if (isOutboundClosed() && !isInboundClosed()) { - // Special case that the outbound was closed, but inbound open. - return HandshakeStatus.NEED_UNWRAP; - } else if (!isOutboundClosed() && isInboundClosed()) { - // Special case that the inbound was closed, but outbound open. - return HandshakeStatus.NEED_WRAP; - } + } // Otherwise, both inbound and outbound are closed return HandshakeStatus.NOT_HANDSHAKING; } > I am confused with what you mean about the copyright year as > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6852be0de227 > > contains no copyright year changes. I'm sorry, I was mistaken. It contains no copyright year changes. Regards, Takuya Kiriyama > -----Original Message----- > From: Andrew Hughes > Sent: Wednesday, June 9, 2021 12:58 PM > To: Kiriyama, Takuya/?? ?? > Cc: 'jdk8u-dev at openjdk.java.net' > Subject: Re: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status > may cause application dead loop > > On 08:59 Mon 07 Jun , kiriyama.takuya at fujitsu.com wrote: > > Hello, > > > > Please reply if anyone can be a sponsor. > > > > Regards, > > Takuya Kiriyama > > > > > -----Original Message----- > > > From: Kiriyama, Takuya/?? ?? > > > Sent: Monday, May 31, 2021 5:58 PM > > > To: 'jdk8u-dev at openjdk.java.net' > > > Subject: [8u] RFR: 8214418 half-closed SSLEngine status may cause > > > application dead loop > > > > > > Hi all, > > > > > > The problem reported by JDK-8214418 occurs on JDK8. > > > I would like to backport 8214418 patch to 8u. But I don't have a JBS > account. > > > Could anybody help me as a sponsor of this backporting ? > > > > > > https://bugs.openjdk.java.net/browse/JDK-8214418 > > > https://hg.openjdk.java.net/jdk/jdk/rev/5022a4915fe9 > > > > > > I don't have access permission to > > > https://bugs.openjdk.java.net/browse/JDK-8214418. > > Neither do I. It looks like the bug is closed. We'll use 8241054 instead. > > > > I can confirm that 8214418 has been backported to JDK11. > > > https://bugs.openjdk.java.net/browse/JDK-8241054 > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6852be0de227 > > > > > > Original patch applied almost clean except for copyright year. > > > I have confirmed that the problem does not occur after backporting with > 8u. > > Please post the patch for review and I can handle the JBS side for you. > > I am confused with what you mean about the copyright year as > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6852be0de227 > > contains no copyright year changes. > > > > > > > Regards, > > > Takuya Kiriyama > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint > = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From kiriyama.takuya at fujitsu.com Fri Jun 25 11:52:11 2021 From: kiriyama.takuya at fujitsu.com (kiriyama.takuya at fujitsu.com) Date: Fri, 25 Jun 2021 11:52:11 +0000 Subject: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status may cause application dead loop In-Reply-To: References: <20210609035732.GB26136@rincewind> Message-ID: Hi Andrew, I understand you are occupied, but I would appreciate it if you would update me on this matter. Regards, Takuya Kiriyama -----Original Message----- From: Kiriyama, Takuya/?? ?? Sent: Thursday, June 10, 2021 5:50 PM To: 'Andrew Hughes' Cc: 'jdk8u-dev at openjdk.java.net' Subject: RE: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status may cause application dead loop Hi Andrew, Thank you for your reply. > Please post the patch for review and I can handle the JBS side for you. Please consider the following code: diff -r -u a/src/share/classes/sun/security/ssl/Ciphertext.java b/src/share/classes/sun/security/ssl/Ciphertext.java --- a/src/share/classes/sun/security/ssl/Ciphertext.java 2021-06-09 21:26:26.762180800 +0900 +++ b/src/share/classes/sun/security/ssl/Ciphertext.java 2021-06-10 09:00:33.660574600 +0900 @@ -31,7 +31,6 @@ * Ciphertext */ final class Ciphertext { - static final Ciphertext CIPHERTEXT_NULL = new Ciphertext(); final byte contentType; final byte handshakeType; diff -r -u a/src/share/classes/sun/security/ssl/SSLEngineImpl.java b/src/share/classes/sun/security/ssl/SSLEngineImpl.java --- a/src/share/classes/sun/security/ssl/SSLEngineImpl.java 2021-06-09 21:26:26.763148800 +0900 +++ b/src/share/classes/sun/security/ssl/SSLEngineImpl.java 2021-06-10 09:19:42.665488000 +0900 @@ -227,6 +227,19 @@ hsStatus = ciphertext.handshakeStatus; } else { hsStatus = getHandshakeStatus(); + if (ciphertext == null && !conContext.isNegotiated && + conContext.isInboundClosed() && + hsStatus == HandshakeStatus.NEED_WRAP) { + // Even the outboud is open, no futher data could be wrapped as: + // 1. the outbound is empty + // 2. no negotiated connection + // 3. the inbound has closed, cannot complete the handshake + // + // Mark the engine as closed if the handshake status is + // NEED_WRAP. Otherwise, it could lead to dead loops in + // applications. + status = Status.CLOSED; + } } int deltaSrcs = srcsRemains; @@ -258,7 +271,7 @@ } if (ciphertext == null) { - return Ciphertext.CIPHERTEXT_NULL; + return null; } // Is the handshake completed? diff -r -u a/src/share/classes/sun/security/ssl/TransportContext.java b/src/share/classes/sun/security/ssl/TransportContext.java --- a/src/share/classes/sun/security/ssl/TransportContext.java 2021-06-09 21:26:26.766062300 +0900 +++ b/src/share/classes/sun/security/ssl/TransportContext.java 2021-06-10 09:14:04.842253500 +0900 @@ -577,13 +577,7 @@ // Special case that the inbound was closed, but outbound open. return HandshakeStatus.NEED_WRAP; } - } else if (isOutboundClosed() && !isInboundClosed()) { - // Special case that the outbound was closed, but inbound open. - return HandshakeStatus.NEED_UNWRAP; - } else if (!isOutboundClosed() && isInboundClosed()) { - // Special case that the inbound was closed, but outbound open. - return HandshakeStatus.NEED_WRAP; - } + } // Otherwise, both inbound and outbound are closed return HandshakeStatus.NOT_HANDSHAKING; } > I am confused with what you mean about the copyright year as > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6852be0de227 > > contains no copyright year changes. I'm sorry, I was mistaken. It contains no copyright year changes. Regards, Takuya Kiriyama > -----Original Message----- > From: Andrew Hughes > Sent: Wednesday, June 9, 2021 12:58 PM > To: Kiriyama, Takuya/?? ?? > Cc: 'jdk8u-dev at openjdk.java.net' > Subject: Re: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status > may cause application dead loop > > On 08:59 Mon 07 Jun , kiriyama.takuya at fujitsu.com wrote: > > Hello, > > > > Please reply if anyone can be a sponsor. > > > > Regards, > > Takuya Kiriyama > > > > > -----Original Message----- > > > From: Kiriyama, Takuya/?? ?? > > > Sent: Monday, May 31, 2021 5:58 PM > > > To: 'jdk8u-dev at openjdk.java.net' > > > Subject: [8u] RFR: 8214418 half-closed SSLEngine status may cause > > > application dead loop > > > > > > Hi all, > > > > > > The problem reported by JDK-8214418 occurs on JDK8. > > > I would like to backport 8214418 patch to 8u. But I don't have a > > > JBS > account. > > > Could anybody help me as a sponsor of this backporting ? > > > > > > https://bugs.openjdk.java.net/browse/JDK-8214418 > > > https://hg.openjdk.java.net/jdk/jdk/rev/5022a4915fe9 > > > > > > I don't have access permission to > > > https://bugs.openjdk.java.net/browse/JDK-8214418. > > Neither do I. It looks like the bug is closed. We'll use 8241054 instead. > > > > I can confirm that 8214418 has been backported to JDK11. > > > https://bugs.openjdk.java.net/browse/JDK-8241054 > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6852be0de227 > > > > > > Original patch applied almost clean except for copyright year. > > > I have confirmed that the problem does not occur after backporting > > > with > 8u. > > Please post the patch for review and I can handle the JBS side for you. > > I am confused with what you mean about the copyright year as > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6852be0de227 > > contains no copyright year changes. > > > > > > > Regards, > > > Takuya Kiriyama > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint > = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From Alan.Hayward at arm.com Fri Jun 25 12:37:46 2021 From: Alan.Hayward at arm.com (Alan Hayward) Date: Fri, 25 Jun 2021 12:37:46 +0000 Subject: [8u] 8266749: AArch64: Backtracing broken on PAC enabled systems Message-ID: <12F76449-F4A4-4531-ADAA-9D448E76BAE4@arm.com> Hi, I?d like to backport this fix. Webrev: http://cr.openjdk.java.net/~ahayward/8266749/webrev/ On fedora 33 (and onwards), openJDK is build with PAC enabled on Aarch64. This patch is require to make the backtracking work. Tested manually on Fedora 33 on a PAC system (VM on M1 Mac) Applied cleanly from TIP version, except for * Files moved into VM directories * New Windows and Mac files removed from patch. I also have an 11u version awaiting review here: https://github.com/openjdk/jdk11u-dev/pull/39 (First time using webrev and back porting, so apologies if I?ve missed something) Thanks, Alan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From hohensee at amazon.com Wed Jun 30 16:37:10 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Jun 2021 16:37:10 +0000 Subject: [8u] RFR 8266749: AArch64: Backtracing broken on PAC enabled systems Message-ID: <8F7FC887-2EDE-4086-B40E-AC74B61E5FA4@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alan Hayward Date: Tuesday, June 29, 2021 at 2:34 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR 8266749: AArch64: Backtracing broken on PAC enabled systems Hi, I?d like to backport this fix. Webrev: http://cr.openjdk.java.net/~ahayward/8266749/webrev/ On fedora 33 (and onwards), openJDK is build with PAC enabled on Aarch64. This patch is required to make the backtracking work. Tested manually on Fedora 33 on a PAC system (VM on M1 Mac) Applied cleanly from TIP version, except for * Files moved into VM directories * New Windows and Mac files removed from patch. I also have an 11u version awaiting review here: https://github.com/openjdk/jdk11u-dev/pull/39 (First time using webrev and back porting, so apologies if I?ve missed something) Thanks, Alan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From aph at redhat.com Wed Jun 30 16:40:47 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Jun 2021 17:40:47 +0100 Subject: Remove some compiling warning, please check it In-Reply-To: <76b39ac4.17b1.17a5d289df8.Coremail.quantum6@yeah.net> References: <76b39ac4.17b1.17a5d289df8.Coremail.quantum6@yeah.net> Message-ID: <98003969-f47a-25ed-343c-d46814a3f975@redhat.com> On 6/30/21 2:43 PM, ??? wrote: > Hello all: > I compile OpenJDK8 many times. I found some commen errors would be warned. > the attach files is modified. Please check it. For this to work, please 1. Tell us what the warnings were, and when it happened. 2. Send your changes in the form of a diff, generated by "hg diff" on the checked-out source code. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671