From robert.field at oracle.com Wed Feb 7 06:48:34 2018 From: robert.field at oracle.com (Robert Field) Date: Tue, 6 Feb 2018 22:48:34 -0800 Subject: RFR 8196133: JShell crashes when attempting to use bad source file in class path Message-ID: <84648bbc-f98c-492d-0b24-2185fa09e994@oracle.com> Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8196133 Webrev: ??? http://cr.openjdk.java.net/~rfield/8196133v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Thu Feb 8 15:55:22 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 8 Feb 2018 16:55:22 +0100 Subject: RFR 8196133: JShell crashes when attempting to use bad source file in class path In-Reply-To: <84648bbc-f98c-492d-0b24-2185fa09e994@oracle.com> References: <84648bbc-f98c-492d-0b24-2185fa09e994@oracle.com> Message-ID: <5A7C72EA.5000301@oracle.com> Looks OK to me. Jan On 7.2.2018 07:48, Robert Field wrote: > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8196133 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8196133v0.webrev/ > > > Thanks, > > Robert > > From jan.lahoda at oracle.com Fri Feb 9 09:31:38 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 9 Feb 2018 10:31:38 +0100 Subject: RFR : JDK-8197439,,Crash with -XDfind=lambda for anonymous class in anonymous class. Message-ID: <5A7D6A7A.2040505@oracle.com> Hi, For certain classes -XDfind=lambda will crash javac (please see the bug for details): --- public class AnonymousInAnonymous { static void s(I1 i) {} static { s( new I1() { public I2 get() { return new I2() { }; } }); } public static interface I1 { public static class I2 { } public I2 get(); } } --- The reason is that: - -XDfind=lambda will try to replace "new I1() {...}" with a lambda and attribute that -but this will make I2 unresolvable -so Attr.visitNewClass will not (currently) attribute the inside of the "new I2() {}". -so Attr.PostAttrAnalyzer will try to fill in Symbols and Types, but "Attr.PostAttrAnalyzer.dummyMethodType" will dereference MethodTree.restype, which is null for constructors (in this case an automatically generated constructor). A part of the proposed fix is to enhance PostAttrAnalyzer.dummyMethodType to handle constructors. But attributing the body of an unresolvable anonymous class does not seem difficult, and would help API clients like JShell, so the proposed fix is doing that as well. One of the changes to do that also removes follow up errors that appear to be unnecessary (an error has already been reported to the anonymous class' "clazz", so unnecessary to report errors that relate to the anonymous class' constructor). Bug: https://bugs.openjdk.java.net/browse/JDK-8197439 Webrev: http://cr.openjdk.java.net/~jlahoda/8197439/webrev.00/ How does this look? Thanks, Jan From robert.field at oracle.com Wed Feb 21 06:26:41 2018 From: robert.field at oracle.com (Robert Field) Date: Tue, 20 Feb 2018 22:26:41 -0800 Subject: RFR 8166232: jshell tool: cannot access previous history Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8166232 Webrev: http://cr.openjdk.java.net/~rfield/8166232v0.webrev/ Thanks, Robert From maurizio.cimadamore at oracle.com Wed Feb 21 18:05:37 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Feb 2018 18:05:37 +0000 Subject: RFR : JDK-8197439, , Crash with -XDfind=lambda for anonymous class in anonymous class. In-Reply-To: <5A7D6A7A.2040505@oracle.com> References: <5A7D6A7A.2040505@oracle.com> Message-ID: <2824b322-9abb-e1a0-4134-b86755d9c834@oracle.com> Looks good - I'm mildly worried that attributing things inside a class w/o supertype might lead to issues - but as we chatted offline, that doesn't seem to be the case, so I'm approving. Cheers Maurizio On 09/02/18 09:31, Jan Lahoda wrote: > Hi, > > For certain classes -XDfind=lambda will crash javac (please see the > bug for details): > --- > public class AnonymousInAnonymous { > ??? static void s(I1 i) {} > ??? static { > ??????? s( > ??????????? new I1() { > ??????????????? public I2 get() { > ??????????????????? return new I2() { > ??????????????????? }; > ??????????????? } > ??????????? }); > ??? } > ??? public static interface I1 { > ??????? public static class I2 { } > ??????? public I2 get(); > ??? } > } > --- > > The reason is that: > - -XDfind=lambda will try to replace "new I1() {...}" with a lambda > and attribute that > -but this will make I2 unresolvable > -so Attr.visitNewClass will not (currently) attribute the inside of > the "new I2() {}". > -so Attr.PostAttrAnalyzer will try to fill in Symbols and Types, but > "Attr.PostAttrAnalyzer.dummyMethodType" will dereference > MethodTree.restype, which is null for constructors (in this case an > automatically generated constructor). > > A part of the proposed fix is to enhance > PostAttrAnalyzer.dummyMethodType to handle constructors. But > attributing the body of an unresolvable anonymous class does not seem > difficult, and would help API clients like JShell, so the proposed fix > is doing that as well. One of the changes to do that also removes > follow up errors that appear to be unnecessary (an error has already > been reported to the anonymous class' "clazz", so unnecessary to > report errors that relate to the anonymous class' constructor). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8197439 > Webrev: http://cr.openjdk.java.net/~jlahoda/8197439/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From robert.field at oracle.com Thu Feb 22 03:57:05 2018 From: robert.field at oracle.com (Robert Field) Date: Wed, 21 Feb 2018 19:57:05 -0800 Subject: RFR 8176474: test/jdk/jshell/JdiBogusHostListenExecutionControlTest.java fails with java.net.BindException Message-ID: Please review. Overly specific assumption of failure mode mode was tested. Check for JShell specific components. Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8176474 Webrev: ??? http://cr.openjdk.java.net/~rfield/8176474v0.webrev/ Thanks, Robert From sormuras at gmail.com Thu Feb 22 14:54:30 2018 From: sormuras at gmail.com (Christian Stein) Date: Thu, 22 Feb 2018 15:54:30 +0100 Subject: Local execution mode and local variables Message-ID: Hi, The following script leads to unexpected loss of an object reference when jshell is launched with option "--execution local": class A { int a() { int error = 0; return error; } } A a = new A() System.out.println("before error | a = " + a) int error = 4711 System.out.println("after error | a = " + a) System.out.println(" error = " + error) /exit Normal mode: jshell execution-local-fails.jsh before error | a = REPL.$JShell$11$A at 7d9d1a19 after error | a = REPL.$JShell$11$A at 7d9d1a19 error = 4711 Local mode: jshell --execution local execution-local-fails.jsh before error | a = REPL.$JShell$11$A at 25df00a0 after error | a = null error = 4711 Is this behaviour expected? Tested on 9.0.1, 9.0.4 and current 10+44. Work around in "local mode": use a different name for the local variable. Cheers, Christian From jan.lahoda at oracle.com Thu Feb 22 17:56:51 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 22 Feb 2018 18:56:51 +0100 Subject: RFR 8176474: test/jdk/jshell/JdiBogusHostListenExecutionControlTest.java fails with java.net.BindException In-Reply-To: References: Message-ID: <5A8F0463.2030906@oracle.com> Looks OK. Jan On 22.2.2018 04:57, Robert Field wrote: > Please review. > > Overly specific assumption of failure mode mode was tested. Check for > JShell specific components. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8176474 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8176474v0.webrev/ > > > Thanks, > Robert > > From robert.field at oracle.com Thu Feb 22 20:56:48 2018 From: robert.field at oracle.com (Robert Field) Date: Thu, 22 Feb 2018 12:56:48 -0800 Subject: Local execution mode and local variables In-Reply-To: References: Message-ID: <0dc39c52-c343-1cf1-9992-8c605aae9b37@oracle.com> Hi Christian, Thanks for your question. Let me start by saying local execution mode is not the intended mode of use. Interesting case. Local execution mode cannot do redefinition, wherein a class is updated in-place, so updates are done by replacing the class, when replaced instances of the old class are lost, hence the null you are seeing. Class A is tagged for update because of a false-positive matching the name of the two variables.? Usually false positives are harmless because the class is redefined with itself, but, per the above, local execution loses the instance. I am submitting a bug because there are several options for handling this better: ????? https://bugs.openjdk.java.net/browse/JDK-8198573 The false positive could be detected in the compiler tree or bytecode. More importantly, in a case requiring an actual replace in normal execution mode the instance is lost which is surprising.? Instance recreation could be examined.? At a minimum, the replacement event should be exposed to JShell tool users. Thanks, Robert On 02/22/18 06:54, Christian Stein wrote: > Hi, > > The following script leads to unexpected loss > of an object reference when jshell is launched > with option "--execution local": > > class A { int a() { int error = 0; return error; } } > A a = new A() > System.out.println("before error | a = " + a) > int error = 4711 > System.out.println("after error | a = " + a) > System.out.println(" error = " + error) > /exit > > Normal mode: > > jshell execution-local-fails.jsh > > before error | a = REPL.$JShell$11$A at 7d9d1a19 > after error | a = REPL.$JShell$11$A at 7d9d1a19 > error = 4711 > > > Local mode: > > jshell --execution local execution-local-fails.jsh > > before error | a = REPL.$JShell$11$A at 25df00a0 > after error | a = null > error = 4711 > > > > Is this behaviour expected? > > Tested on 9.0.1, 9.0.4 and current 10+44. > > Work around in "local mode": use a different > name for the local variable. > > Cheers, > Christian From robert.field at oracle.com Fri Feb 23 00:31:09 2018 From: robert.field at oracle.com (Robert Field) Date: Thu, 22 Feb 2018 16:31:09 -0800 Subject: RFR 8198573: JShell: class replace loses instances Message-ID: Possible update false-positives are tested with a bytecode comparison.? This is thwarted because the continuously growing list of imports are put on new lines which changes the line-number table.? With local execution this causes loss of data.? Fix by keeping all imports on a single line. Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8198573 Webrev: ??? http://cr.openjdk.java.net/~rfield/8198573v0.webrev/ Thanks, Robert From sormuras at gmail.com Fri Feb 23 08:33:16 2018 From: sormuras at gmail.com (Christian Stein) Date: Fri, 23 Feb 2018 09:33:16 +0100 Subject: RFR 8198573: JShell: class replace loses instances In-Reply-To: References: Message-ID: Looking forward to the first 11-ea build. Thanks for the quick fix, Christian From jan.lahoda at oracle.com Fri Feb 23 12:25:35 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 23 Feb 2018 13:25:35 +0100 Subject: RFR 8166232: jshell tool: cannot access previous history In-Reply-To: References: Message-ID: <5A90083F.4000502@oracle.com> Seems good to me. Jan On 21.2.2018 07:26, Robert Field wrote: > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8166232 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8166232v0.webrev/ > > Thanks, > Robert > From jan.lahoda at oracle.com Fri Feb 23 16:06:43 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 23 Feb 2018 17:06:43 +0100 Subject: RFR 8198573: JShell: class replace loses instances In-Reply-To: References: Message-ID: <5A903C13.8040508@oracle.com> Seems OK to me. Jan On 23.2.2018 01:31, Robert Field wrote: > Possible update false-positives are tested with a bytecode comparison. > This is thwarted because the continuously growing list of imports are > put on new lines which changes the line-number table. With local > execution this causes loss of data. Fix by keeping all imports on a > single line. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8198573 > > Webrev: > > http://cr.openjdk.java.net/~rfield/8198573v0.webrev/ > > > Thanks, > Robert > > From robert.field at oracle.com Mon Feb 26 04:47:46 2018 From: robert.field at oracle.com (Robert Field) Date: Sun, 25 Feb 2018 20:47:46 -0800 Subject: RFR 819867: [testbug] Test jdk/internal/jline/extra/HistoryTest.java is broken after 8166232 Message-ID: Please review. Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8198670 Webrev: ??? http://cr.openjdk.java.net/~rfield/8198670v0.webrev/ Thanks, Robert From jan.lahoda at oracle.com Mon Feb 26 06:41:05 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 26 Feb 2018 07:41:05 +0100 Subject: RFR 819867: [testbug] Test jdk/internal/jline/extra/HistoryTest.java is broken after 8166232 In-Reply-To: References: Message-ID: <5A93AC01.1060702@oracle.com> Looks good. Maybe update the year in the copyright to 2018? Jan On 26.2.2018 05:47, Robert Field wrote: > Please review. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8198670 > > Webrev: > http://cr.openjdk.java.net/~rfield/8198670v0.webrev/ > > Thanks, > Robert > > From robert.field at oracle.com Mon Feb 26 16:40:28 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 26 Feb 2018 08:40:28 -0800 Subject: RFR 8184445: JShell tests: fail intermittently if tests are run in high concurrent mode. Message-ID: Please review. Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8184445 Webrev: ??? http://cr.openjdk.java.net/~rfield/8184445v0.webrev/ Thanks, Robert From joe.darcy at oracle.com Mon Feb 26 18:23:37 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 26 Feb 2018 10:23:37 -0800 Subject: RFR 8184445: JShell tests: fail intermittently if tests are run in high concurrent mode. In-Reply-To: References: Message-ID: <5a77bf38-7ce4-35c9-4721-65482b9a8fae@oracle.com> Hi Robert, The fix looks acceptable in terms of addressing the problem, but is there a sense of how this might impact running time of the test suite? Phrased differently, are there plans to make the tests more robust to concurrent runs in the future? Thanks, -Joe On 2/26/2018 8:40 AM, Robert Field wrote: > Please review. > > Bug: > ??? https://bugs.openjdk.java.net/browse/JDK-8184445 > > Webrev: > ??? http://cr.openjdk.java.net/~rfield/8184445v0.webrev/ > > Thanks, > Robert > From robert.field at oracle.com Mon Feb 26 18:57:26 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 26 Feb 2018 10:57:26 -0800 Subject: RFR 8184445: JShell tests: fail intermittently if tests are run in high concurrent mode. In-Reply-To: <5a77bf38-7ce4-35c9-4721-65482b9a8fae@oracle.com> References: <5a77bf38-7ce4-35c9-4721-65482b9a8fae@oracle.com> Message-ID: <52c15ebf-9adb-07ef-7d30-69ebbe6c598f@oracle.com> On 02/26/18 10:23, joe darcy wrote: > Hi Robert, > > The fix looks acceptable in terms of addressing the problem, but is > there a sense of how this might impact running time of the test suite? > > Phrased differently, are there plans to make the tests more robust to > concurrent runs in the future? Hi Joe, There is a lot of network connection happening in these tests, most of which is in layers we don't control (JDI).? We have been trying to lower the risk and we don't see failures running the tests ourselves, but intermittent failures scattered through the suite during testing (e.g. mach5) have been a constant problem. We will see the impact on test duration.? Default connection has three-level fail-over, the tests of other connection modes see failure far more frequently, so, if necessary, we can look at tuning this. -Robert > > Thanks, > > -Joe > > > On 2/26/2018 8:40 AM, Robert Field wrote: >> Please review. >> >> Bug: >> ??? https://bugs.openjdk.java.net/browse/JDK-8184445 >> >> Webrev: >> ??? http://cr.openjdk.java.net/~rfield/8184445v0.webrev/ >> >> Thanks, >> Robert >> > From joe.darcy at oracle.com Tue Feb 27 01:28:48 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 26 Feb 2018 17:28:48 -0800 Subject: RFR 8184445: JShell tests: fail intermittently if tests are run in high concurrent mode. In-Reply-To: <52c15ebf-9adb-07ef-7d30-69ebbe6c598f@oracle.com> References: <5a77bf38-7ce4-35c9-4721-65482b9a8fae@oracle.com> <52c15ebf-9adb-07ef-7d30-69ebbe6c598f@oracle.com> Message-ID: Hi Robert, On 2/26/2018 10:57 AM, Robert Field wrote: > > > On 02/26/18 10:23, joe darcy wrote: >> Hi Robert, >> >> The fix looks acceptable in terms of addressing the problem, but is >> there a sense of how this might impact running time of the test suite? >> >> Phrased differently, are there plans to make the tests more robust to >> concurrent runs in the future? > > Hi Joe, > > There is a lot of network connection happening in these tests, most of > which is in layers we don't control (JDI).? We have been trying to > lower the risk and we don't see failures running the tests ourselves, > but intermittent failures scattered through the suite during testing > (e.g. mach5) have been a constant problem. > > We will see the impact on test duration.? Default connection has > three-level fail-over, the tests of other connection modes see failure > far more frequently, so, if necessary, we can look at tuning this. > From some quick checking, there are about 80 tests in that directory. From one sample point on my laptop, the tests took a good long while to run. If some of the tests can be reliably run concurrently, I'd much prefer to see a subset of tests moved to a sheltered directory. Thanks, -Joe From robert.field at oracle.com Tue Feb 27 20:21:17 2018 From: robert.field at oracle.com (Robert Field) Date: Tue, 27 Feb 2018 12:21:17 -0800 Subject: RFR 8184445: JShell tests: fail intermittently if tests are run in high concurrent mode. In-Reply-To: References: <5a77bf38-7ce4-35c9-4721-65482b9a8fae@oracle.com> <52c15ebf-9adb-07ef-7d30-69ebbe6c598f@oracle.com> Message-ID: <5105b8c9-784b-c878-aff6-134dcb6bedfc@oracle.com> OK, I did a survey of all the JShell bugs.? There are over a dozen intermittent test failures, almost all are probably network related.? But if we limit to just intermittent failures to launch, then there are seven. There are 17 tests of launching configuration, and 75 'normal' tests.? So, the launching configuration tests do fail disproportionately, 3 mentioned failures vs 5 mentioned failing files. The bug that highlighted the concurrent testing -- "JShell tests: fail intermittently if tests are run in high concurrent mode": ??? https://bugs.openjdk.java.net/browse/JDK-8184445 mentioned 'several' issues, the two included JTR files are, tellingly, normal tests. The non-launching intermittent failures are all normal tests. So, where does that leave us?? I could reduce the failures a bit at low time-cost by putting the launching configuration tests in the exclusiveAccess.dirs.? Or, I could, at considerable testing cost, address the broad swath. -Robert On 02/26/18 17:28, joe darcy wrote: > Hi Robert, > > On 2/26/2018 10:57 AM, Robert Field wrote: >> >> >> On 02/26/18 10:23, joe darcy wrote: >>> Hi Robert, >>> >>> The fix looks acceptable in terms of addressing the problem, but is >>> there a sense of how this might impact running time of the test suite? >>> >>> Phrased differently, are there plans to make the tests more robust >>> to concurrent runs in the future? >> >> Hi Joe, >> >> There is a lot of network connection happening in these tests, most >> of which is in layers we don't control (JDI).? We have been trying to >> lower the risk and we don't see failures running the tests ourselves, >> but intermittent failures scattered through the suite during testing >> (e.g. mach5) have been a constant problem. >> >> We will see the impact on test duration.? Default connection has >> three-level fail-over, the tests of other connection modes see >> failure far more frequently, so, if necessary, we can look at tuning >> this. >> > > From some quick checking, there are about 80 tests in that directory. > From one sample point on my laptop, the tests took a good long while > to run. If some of the tests can be reliably run concurrently, I'd > much prefer to see a subset of tests moved to a sheltered directory. > > Thanks, > > -Joe From brian.goetz at oracle.com Tue Feb 27 23:45:50 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 27 Feb 2018 18:45:50 -0500 Subject: Chained exception handling: bug? Message-ID: <6cc0a2d2-efdb-b8bc-8b09-9ee111df8a30@oracle.com> If I evaluate an expression which results in throwing an exception, and that exception has a cause, the cause is not included in the stack trace: jshell> $8.resolveConstantRef(MethodHandles.lookup()) |? java.lang.BootstrapMethodError thrown: bootstrap method initialization exception |??????? at BootstrapMethodInvoker.invoke (BootstrapMethodInvoker.java:174) |??????? at ConstantBootstraps.makeConstant (ConstantBootstraps.java:66) |??????? at DynamicConstantRef.resolveConstantRef (DynamicConstantRef.java:308) |??????? at (#22:1) This exception had a chained cause, but it wasn't displayed.? Was the choice to only process the first exception in the chain deliberate, or is this an omission?? (Its pretty hard to debug the above without the underlying cause.) From forax at univ-mlv.fr Wed Feb 28 00:00:45 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 28 Feb 2018 01:00:45 +0100 (CET) Subject: Chained exception handling: bug? In-Reply-To: <6cc0a2d2-efdb-b8bc-8b09-9ee111df8a30@oracle.com> References: <6cc0a2d2-efdb-b8bc-8b09-9ee111df8a30@oracle.com> Message-ID: <1752024021.838386.1519776045831.JavaMail.zimbra@u-pem.fr> Funny, i've hit this exact same issue earlier in the morning. R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "kulla-dev" > Envoy?: Mercredi 28 F?vrier 2018 00:45:50 > Objet: Chained exception handling: bug? > If I evaluate an expression which results in throwing an exception, and > that exception has a cause, the cause is not included in the stack trace: > > jshell> $8.resolveConstantRef(MethodHandles.lookup()) >|? java.lang.BootstrapMethodError thrown: bootstrap method > initialization exception >|??????? at BootstrapMethodInvoker.invoke (BootstrapMethodInvoker.java:174) >|??????? at ConstantBootstraps.makeConstant (ConstantBootstraps.java:66) >|??????? at DynamicConstantRef.resolveConstantRef > (DynamicConstantRef.java:308) >|??????? at (#22:1) > > This exception had a chained cause, but it wasn't displayed.? Was the > choice to only process the first exception in the chain deliberate, or > is this an omission?? (Its pretty hard to debug the above without the > underlying cause.) From robert.field at oracle.com Wed Feb 28 01:01:04 2018 From: robert.field at oracle.com (Robert Field) Date: Tue, 27 Feb 2018 17:01:04 -0800 Subject: Chained exception handling: bug? In-Reply-To: <1752024021.838386.1519776045831.JavaMail.zimbra@u-pem.fr> References: <6cc0a2d2-efdb-b8bc-8b09-9ee111df8a30@oracle.com> <1752024021.838386.1519776045831.JavaMail.zimbra@u-pem.fr> Message-ID: Brian, yeah, yeah, that was it, a keep it simple choice. R?mi, as you both hit this -- the same day! -- I think it merits addressing, soon. I've created: ???? https://bugs.openjdk.java.net/browse/JDK-8198801 And I'm looking at it now.? Bit of a pain since it propagates from the back-end, so requires an SPI change. -Robert On 02/27/18 16:00, Remi Forax wrote: > Funny, i've hit this exact same issue earlier in the morning. > > R?mi > > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "kulla-dev" >> Envoy?: Mercredi 28 F?vrier 2018 00:45:50 >> Objet: Chained exception handling: bug? >> If I evaluate an expression which results in throwing an exception, and >> that exception has a cause, the cause is not included in the stack trace: >> >> jshell> $8.resolveConstantRef(MethodHandles.lookup()) >> |? java.lang.BootstrapMethodError thrown: bootstrap method >> initialization exception >> |??????? at BootstrapMethodInvoker.invoke (BootstrapMethodInvoker.java:174) >> |??????? at ConstantBootstraps.makeConstant (ConstantBootstraps.java:66) >> |??????? at DynamicConstantRef.resolveConstantRef >> (DynamicConstantRef.java:308) >> |??????? at (#22:1) >> >> This exception had a chained cause, but it wasn't displayed.? Was the >> choice to only process the first exception in the chain deliberate, or >> is this an omission?? (Its pretty hard to debug the above without the >> underlying cause.) From robert.field at oracle.com Wed Feb 28 01:15:30 2018 From: robert.field at oracle.com (Robert Field) Date: Tue, 27 Feb 2018 17:15:30 -0800 Subject: Chained exception handling: bug? In-Reply-To: References: <6cc0a2d2-efdb-b8bc-8b09-9ee111df8a30@oracle.com> <1752024021.838386.1519776045831.JavaMail.zimbra@u-pem.fr> Message-ID: <9f338310-f19b-f435-cf3d-873f47847a98@oracle.com> Fixing this will require the back-end to send a result type that a prior version front-end would flag as a bad result code.? In that this will not break ExecutionControl instances written to the old SPI, I believe this is fine.? Yes? -Robert On 02/27/18 17:01, Robert Field wrote: > Brian, yeah, yeah, that was it, a keep it simple choice. > > R?mi, as you both hit this -- the same day! -- I think it merits > addressing, soon. > > I've created: > > ???? https://bugs.openjdk.java.net/browse/JDK-8198801 > > And I'm looking at it now.? Bit of a pain since it propagates from the > back-end, so requires an SPI change. > > -Robert > > > > > On 02/27/18 16:00, Remi Forax wrote: >> Funny, i've hit this exact same issue earlier in the morning. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Brian Goetz" >>> ?: "kulla-dev" >>> Envoy?: Mercredi 28 F?vrier 2018 00:45:50 >>> Objet: Chained exception handling: bug? >>> If I evaluate an expression which results in throwing an exception, and >>> that exception has a cause, the cause is not included in the stack >>> trace: >>> >>> jshell> $8.resolveConstantRef(MethodHandles.lookup()) >>> |? java.lang.BootstrapMethodError thrown: bootstrap method >>> initialization exception >>> |??????? at BootstrapMethodInvoker.invoke >>> (BootstrapMethodInvoker.java:174) >>> |??????? at ConstantBootstraps.makeConstant >>> (ConstantBootstraps.java:66) >>> |??????? at DynamicConstantRef.resolveConstantRef >>> (DynamicConstantRef.java:308) >>> |??????? at (#22:1) >>> >>> This exception had a chained cause, but it wasn't displayed. Was the >>> choice to only process the first exception in the chain deliberate, or >>> is this an omission?? (Its pretty hard to debug the above without the >>> underlying cause.) > From joe.darcy at oracle.com Wed Feb 28 02:14:13 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 27 Feb 2018 18:14:13 -0800 Subject: RFR 8184445: JShell tests: fail intermittently if tests are run in high concurrent mode. In-Reply-To: <5105b8c9-784b-c878-aff6-134dcb6bedfc@oracle.com> References: <5a77bf38-7ce4-35c9-4721-65482b9a8fae@oracle.com> <52c15ebf-9adb-07ef-7d30-69ebbe6c598f@oracle.com> <5105b8c9-784b-c878-aff6-134dcb6bedfc@oracle.com> Message-ID: <5A961075.6060007@oracle.com> Hi Robert, I'd prefer if only the launching tests and other known failures were segregated into a non-concurrent area. That would still let ~3/4 of the tests proceed normally. As a follow-up, can an RFE be filed to harden the intermittently failing tests against concurrent networking? Thanks, -Joe On 2/27/2018 12:21 PM, Robert Field wrote: > OK, I did a survey of all the JShell bugs. There are over a dozen > intermittent test failures, almost all are probably network related. > But if we limit to just intermittent failures to launch, then there > are seven. > > There are 17 tests of launching configuration, and 75 'normal' tests. > So, the launching configuration tests do fail disproportionately, 3 > mentioned failures vs 5 mentioned failing files. > > The bug that highlighted the concurrent testing -- "JShell tests: fail > intermittently if tests are run in high concurrent mode": > https://bugs.openjdk.java.net/browse/JDK-8184445 > mentioned 'several' issues, the two included JTR files are, tellingly, > normal tests. > > The non-launching intermittent failures are all normal tests. > > So, where does that leave us? I could reduce the failures a bit at > low time-cost by putting the launching configuration tests in the > exclusiveAccess.dirs. Or, I could, at considerable testing cost, > address the broad swath. > > -Robert > > On 02/26/18 17:28, joe darcy wrote: >> Hi Robert, >> >> On 2/26/2018 10:57 AM, Robert Field wrote: >>> >>> >>> On 02/26/18 10:23, joe darcy wrote: >>>> Hi Robert, >>>> >>>> The fix looks acceptable in terms of addressing the problem, but is >>>> there a sense of how this might impact running time of the test suite? >>>> >>>> Phrased differently, are there plans to make the tests more robust >>>> to concurrent runs in the future? >>> >>> Hi Joe, >>> >>> There is a lot of network connection happening in these tests, most >>> of which is in layers we don't control (JDI). We have been trying >>> to lower the risk and we don't see failures running the tests >>> ourselves, but intermittent failures scattered through the suite >>> during testing (e.g. mach5) have been a constant problem. >>> >>> We will see the impact on test duration. Default connection has >>> three-level fail-over, the tests of other connection modes see >>> failure far more frequently, so, if necessary, we can look at tuning >>> this. >>> >> >> From some quick checking, there are about 80 tests in that directory. >> From one sample point on my laptop, the tests took a good long while >> to run. If some of the tests can be reliably run concurrently, I'd >> much prefer to see a subset of tests moved to a sheltered directory. >> >> Thanks, >> >> -Joe >