From nicholas+openjdk at nicholaswilliams.net Thu Aug 1 10:38:38 2013 From: nicholas+openjdk at nicholaswilliams.net (Nick Williams) Date: Thu, 1 Aug 2013 12:38:38 -0500 Subject: Try to run core libs tests -- All IO tests failing In-Reply-To: <51F92947.70402@oracle.com> References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net> <51F80198.4050209@oracle.com> <51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com> <51F92947.70402@oracle.com> Message-ID: <437338A3-91DE-4ABB-A89A-B9104090410B@nicholaswilliams.net> That was the ticket! All the tests run with this command, despite the fact that some of them fail. Thanks! You might want to update the readme with this command, at least as an alternative to the one there now. Nick On Jul 31, 2013, at 10:12 AM, Chris Hegarty wrote: > > try: > make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ *jdk_core* > > -Chris. > > On 31/07/2013 15:49, Nick Williams wrote: >> That's how I'm running it. >> >> $ pwd >> /foo/bar/jdk8/jdk8 >> $ cd test >> $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all >> >> If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment. >> >> Nick >> >> On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote: >> >>> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run. >>> >>> -Chris. >>> >>> On 30/07/2013 21:46, Jonathan Gibbons wrote: >>>> >>>> jtreg itself does not "stop on error". If you're driving the tests >>>> through the makefiles, the makefiles may partition the work into >>>> separate jtreg runs on separate parts of the test suite. >>>> >>>> -- Jon >>>> >>>> >>>> On 07/30/2013 01:13 PM, Nick Williams wrote: >>>>> Okay, this is indeed very interesting. After two hours it was only >>>>> about half-way through the java.io tests and all of them had failed so >>>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable, >>>>> thus disconnecting me from any/all networks and the Internet. BOOM. >>>>> The rest of the java.io tests finished (and passed) in a few seconds, >>>>> leaving 137 that had failed. I then re-ran the tests while still >>>>> disconnected from the Internet and 312 of the java.io tests passed >>>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, >>>>> output below). >>>>> >>>>> I plugged my Ethernet back in and ran the tests again and java.io >>>>> started failing every test again, timing out after 60 seconds each. >>>>> Curiously extending my hunch I remained connected over Ethernet and >>>>> connected to a remote network via OpenVPN. Now all of the java.io test >>>>> pass again (except that same one, with the same output). >>>>> >>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.) >>>>> >>>>> Unfortunately, the one failed java.io test prevents jtreg from >>>>> continuing on to the next set of tests (java.lang). Anyone know how to >>>>> tell jtreg to continue running on error? >>>>> >>>>> Nick >>>>> >>>>> #Test Results (version 2) >>>>> #Tue Jul 30 14:53:42 CDT 2013 >>>>> #-----testdescription----- >>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java >>>>> >>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>> keywords=bug8003258 >>>>> run=USER_SPECIFIED testng Lines\n >>>>> source=Lines.java >>>>> title=\ >>>>> >>>>> #-----environment----- >>>>> >>>>> #-----testresult----- >>>>> end=Tue Jul 30 14\:53\:42 CDT 2013 >>>>> execStatus=Error. Unexpected exception caught from test >>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException >>>>> sections=script_messages Details >>>>> >>>>> #section:script_messages >>>>> ----------messages:(0/0)---------- >>>>> >>>>> #section:Details >>>>> ----------messages:(0/0)---------- >>>>> ----------Stack trace:(10/672)---------- >>>>> java.lang.NullPointerException >>>>> at >>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97) >>>>> >>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80) >>>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131) >>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260) >>>>> at >>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149) >>>>> at com.sun.javatest.Script.run(Script.java:228) >>>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174) >>>>> at >>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43) >>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66) >>>>> result: Not run. Test running... >>>>> >>>>> >>>>> test result: Error. Unexpected exception caught from test >>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException >>>>> >>>>> >>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote: >>>>> >>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote: >>>>>> >>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote: >>>>>>> >>>>>>>> On 30/07/2013 11:02, Nick Williams wrote: >>>>>>>>> I'm running the core libs tests locally (for the first time), and >>>>>>>>> every java.io test is failing. They're all failing for the same >>>>>>>>> reason (output below), and I suspect it's something local and not >>>>>>>>> an actual problem. But the test output is not very helpful. Note >>>>>>>>> that all of the java.beans tests passed with flying colors. Once >>>>>>>>> it got to java.io, everything started failing. Worse, each test is >>>>>>>>> taking 60 seconds to fail. I could be here a while... >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>> What command are you using? From the output it suggests that the >>>>>>>> connection between jtreg and the agent VM cannot be established. >>>>>>>> >>>>>>>> -Alan. >>>>>>> Command, just like README-builds.html#testing says: >>>>>>> >>>>>>> cd test&& make >>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ >>>>>>> all >>>>>>> >>>>>>> I assume this is specifically an java.io-related problem because all >>>>>>> the java.beans tests passed without exception and so far every >>>>>>> java.io test through java.io.Externalizable (that's as far as it has >>>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg >>>>>>> communicating with the agent VM have shown up in java.beans as well? >>>>>>> I could be wrong of course. >>>>>> I see now that java.beans tests run in "othervm mode" while java.io >>>>>> tests run in "agentvm mode." Didn't realize they were being run >>>>>> differently. Your explanation makes much more sense now, but I still >>>>>> don't know what's wrong... >>>>>> >>>>>>>> >>>>>>>>> Here's the output from one of the tests. It looks like all the >>>>>>>>> other test outputs: >>>>>>>>> >>>>>>>>> #Test Results (version 2) >>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013 >>>>>>>>> #-----testdescription----- >>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> >>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>>>>>> keywords=bug4143651 >>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n >>>>>>>>> source=ReadAfterClose.java >>>>>>>>> title=Test if I/O methods will check if the stream has been closed. >>>>>>>>> >>>>>>>>> #-----environment----- >>>>>>>>> >>>>>>>>> #-----testresult----- >>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> >>>>>>>>> elapsed=60007 0\:01\:00.007 >>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013 >>>>>>>>> environment=regtest >>>>>>>>> execStatus=Error. Cannot get VM for test\: >>>>>>>>> java.net.SocketTimeoutException\: Accept timed out >>>>>>>>> hostname=unknown >>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64) >>>>>>>>> javatestVersion=4.4.1 >>>>>>>>> jtregVersion=jtreg 4.1 dev b00 >>>>>>>>> script=com.sun.javatest.regtest.RegressionScript >>>>>>>>> sections=script_messages build compile >>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013 >>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> user.name=Nicholas >>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream >>>>>>>>> >>>>>>>>> >>>>>>>>> #section:script_messages >>>>>>>>> ----------messages:(5/308)---------- >>>>>>>>> JDK under test: >>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image) >>>>>>>>> >>>>>>>>> openjdk version "1.8.0-internal" >>>>>>>>> OpenJDK Runtime Environment (build >>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00) >>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode) >>>>>>>>> >>>>>>>>> >>>>>>>>> #section:build >>>>>>>>> ----------messages:(3/100)---------- >>>>>>>>> command: build ReadAfterClose >>>>>>>>> reason: Named class compiled on demand >>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>> >>>>>>>>> #section:compile >>>>>>>>> ----------messages:(3/235)---------- >>>>>>>>> command: compile -XDignore.symbol.file=true >>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>> >>>>>>>>> reason: .class file out of date or does not exist >>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>> >>>>>>>>> >>>>>>>>> test result: Error. Cannot get VM for test: >>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>> >>>> >> From mike.duigou at oracle.com Thu Aug 1 11:51:51 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 1 Aug 2013 11:51:51 -0700 Subject: Try to run core libs tests -- All IO tests failing In-Reply-To: <437338A3-91DE-4ABB-A89A-B9104090410B@nicholaswilliams.net> References: <68C504A0-F6DE-4A4D-B09C-0EC8FF1137AE@nicholaswilliams.net> <51F80198.4050209@oracle.com> <51F8262A.3060809@oracle.com> <51F922D2.4030305@oracle.com> <51F92947.70402@oracle.com> <437338A3-91DE-4ABB-A89A-B9104090410B@nicholaswilliams.net> Message-ID: <4AAA5CB8-5A6D-4F50-BFC8-6DF3740F87EA@oracle.com> On Aug 1 2013, at 10:38 , Nick Williams wrote: > That was the ticket! All the tests run with this command, despite the fact that some of them fail. Thanks! > > You might want to update the readme with this command, at least as an alternative to the one there now. > > Nick > > On Jul 31, 2013, at 10:12 AM, Chris Hegarty wrote: > >> >> try: >> make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ *jdk_core* An alternative is to use the top level repo make: make test TEST="jdk_core" The jdk/test/Makefile has not been upgraded to understand the location of the built jdk image with the new build infrastructure. I have been doing some work to try to improve the running of tests via make. We haven't yet decided whether running the jdk/test/Makefile directly will remain a supported invocation method. Mike >> >> -Chris. >> >> On 31/07/2013 15:49, Nick Williams wrote: >>> That's how I'm running it. >>> >>> $ pwd >>> /foo/bar/jdk8/jdk8 >>> $ cd test >>> $ make PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ all >>> >>> If one test fails in a batch, none of the following batches run. So if one test fails in java.io, java.lang won't run. Makes it difficult to run all of the tests, especial since there are two tests in java.lang (ThreadLocalSupplierTests due to java.lang.VerifyError: Bad local variable type, and DefaultMethodModeling due to java.lang.NullPointerException at java.util.Objects.requireNonNull when checking class B) that fail consistently (on Mac OS X at least) that I haven't been able to solve by identifying issues with the testing environment. >>> >>> Nick >>> >>> On Jul 31, 2013, at 9:44 AM, Chris Hegarty wrote: >>> >>>> I believe if you run the tests from the top-level test/Makefile, not jdk/test/Makefile, all individual test batches ( invocations of jtreg ) get run. >>>> >>>> -Chris. >>>> >>>> On 30/07/2013 21:46, Jonathan Gibbons wrote: >>>>> >>>>> jtreg itself does not "stop on error". If you're driving the tests >>>>> through the makefiles, the makefiles may partition the work into >>>>> separate jtreg runs on separate parts of the test suite. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> On 07/30/2013 01:13 PM, Nick Williams wrote: >>>>>> Okay, this is indeed very interesting. After two hours it was only >>>>>> about half-way through the java.io tests and all of them had failed so >>>>>> far. On a sheer hunch and nothing more, I unplugged my ethernet cable, >>>>>> thus disconnecting me from any/all networks and the Internet. BOOM. >>>>>> The rest of the java.io tests finished (and passed) in a few seconds, >>>>>> leaving 137 that had failed. I then re-ran the tests while still >>>>>> disconnected from the Internet and 312 of the java.io tests passed >>>>>> this time, leaving only 1 failure (java/io/BufferedReader/Lines.java, >>>>>> output below). >>>>>> >>>>>> I plugged my Ethernet back in and ran the tests again and java.io >>>>>> started failing every test again, timing out after 60 seconds each. >>>>>> Curiously extending my hunch I remained connected over Ethernet and >>>>>> connected to a remote network via OpenVPN. Now all of the java.io test >>>>>> pass again (except that same one, with the same output). >>>>>> >>>>>> What on Earth??? (If it helps, I'm on Mac OS X 10.7.5.) >>>>>> >>>>>> Unfortunately, the one failed java.io test prevents jtreg from >>>>>> continuing on to the next set of tests (java.lang). Anyone know how to >>>>>> tell jtreg to continue running on error? >>>>>> >>>>>> Nick >>>>>> >>>>>> #Test Results (version 2) >>>>>> #Tue Jul 30 14:53:42 CDT 2013 >>>>>> #-----testdescription----- >>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedReader/Lines.java >>>>>> >>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>>> keywords=bug8003258 >>>>>> run=USER_SPECIFIED testng Lines\n >>>>>> source=Lines.java >>>>>> title=\ >>>>>> >>>>>> #-----environment----- >>>>>> >>>>>> #-----testresult----- >>>>>> end=Tue Jul 30 14\:53\:42 CDT 2013 >>>>>> execStatus=Error. Unexpected exception caught from test >>>>>> java/io/BufferedReader/Lines.java\: java.lang.NullPointerException >>>>>> sections=script_messages Details >>>>>> >>>>>> #section:script_messages >>>>>> ----------messages:(0/0)---------- >>>>>> >>>>>> #section:Details >>>>>> ----------messages:(0/0)---------- >>>>>> ----------Stack trace:(10/672)---------- >>>>>> java.lang.NullPointerException >>>>>> at >>>>>> com.sun.javatest.regtest.TestNGReporter.getMatcher(TestNGReporter.java:97) >>>>>> >>>>>> at com.sun.javatest.regtest.TestNGReporter.add(TestNGReporter.java:80) >>>>>> at com.sun.javatest.regtest.TestNGAction.endAction(TestNGAction.java:131) >>>>>> at com.sun.javatest.regtest.MainAction.run(MainAction.java:260) >>>>>> at >>>>>> com.sun.javatest.regtest.RegressionScript.run(RegressionScript.java:149) >>>>>> at com.sun.javatest.Script.run(Script.java:228) >>>>>> at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174) >>>>>> at >>>>>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43) >>>>>> at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66) >>>>>> result: Not run. Test running... >>>>>> >>>>>> >>>>>> test result: Error. Unexpected exception caught from test >>>>>> java/io/BufferedReader/Lines.java: java.lang.NullPointerException >>>>>> >>>>>> >>>>>> On Jul 30, 2013, at 1:39 PM, Nick Williams wrote: >>>>>> >>>>>>> On Jul 30, 2013, at 1:16 PM, Nick Williams wrote: >>>>>>> >>>>>>>> On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote: >>>>>>>> >>>>>>>>> On 30/07/2013 11:02, Nick Williams wrote: >>>>>>>>>> I'm running the core libs tests locally (for the first time), and >>>>>>>>>> every java.io test is failing. They're all failing for the same >>>>>>>>>> reason (output below), and I suspect it's something local and not >>>>>>>>>> an actual problem. But the test output is not very helpful. Note >>>>>>>>>> that all of the java.beans tests passed with flying colors. Once >>>>>>>>>> it got to java.io, everything started failing. Worse, each test is >>>>>>>>>> taking 60 seconds to fail. I could be here a while... >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>> What command are you using? From the output it suggests that the >>>>>>>>> connection between jtreg and the agent VM cannot be established. >>>>>>>>> >>>>>>>>> -Alan. >>>>>>>> Command, just like README-builds.html#testing says: >>>>>>>> >>>>>>>> cd test&& make >>>>>>>> PRODUCT_HOME=`pwd`/../build/macosx-x86_64-normal-server-release/images/j2sdk-image/ >>>>>>>> all >>>>>>>> >>>>>>>> I assume this is specifically an java.io-related problem because all >>>>>>>> the java.beans tests passed without exception and so far every >>>>>>>> java.io test through java.io.Externalizable (that's as far as it has >>>>>>>> gotten) has failed without exception. Wouldn't a problem with jtreg >>>>>>>> communicating with the agent VM have shown up in java.beans as well? >>>>>>>> I could be wrong of course. >>>>>>> I see now that java.beans tests run in "othervm mode" while java.io >>>>>>> tests run in "agentvm mode." Didn't realize they were being run >>>>>>> differently. Your explanation makes much more sense now, but I still >>>>>>> don't know what's wrong... >>>>>>> >>>>>>>>> >>>>>>>>>> Here's the output from one of the tests. It looks like all the >>>>>>>>>> other test outputs: >>>>>>>>>> >>>>>>>>>> #Test Results (version 2) >>>>>>>>>> #Tue Jul 30 12:38:15 CDT 2013 >>>>>>>>>> #-----testdescription----- >>>>>>>>>> $file=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> >>>>>>>>>> $root=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test >>>>>>>>>> keywords=bug4143651 >>>>>>>>>> run=ASSUMED_ACTION main ReadAfterClose\n >>>>>>>>>> source=ReadAfterClose.java >>>>>>>>>> title=Test if I/O methods will check if the stream has been closed. >>>>>>>>>> >>>>>>>>>> #-----environment----- >>>>>>>>>> >>>>>>>>>> #-----testresult----- >>>>>>>>>> description=file\:/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> >>>>>>>>>> elapsed=60007 0\:01\:00.007 >>>>>>>>>> end=Tue Jul 30 12\:38\:15 CDT 2013 >>>>>>>>>> environment=regtest >>>>>>>>>> execStatus=Error. Cannot get VM for test\: >>>>>>>>>> java.net.SocketTimeoutException\: Accept timed out >>>>>>>>>> hostname=unknown >>>>>>>>>> javatestOS=Mac OS X 10.7.5 (x86_64) >>>>>>>>>> javatestVersion=4.4.1 >>>>>>>>>> jtregVersion=jtreg 4.1 dev b00 >>>>>>>>>> script=com.sun.javatest.regtest.RegressionScript >>>>>>>>>> sections=script_messages build compile >>>>>>>>>> start=Tue Jul 30 12\:37\:15 CDT 2013 >>>>>>>>>> test=java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> user.name=Nicholas >>>>>>>>>> work=/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/build/macosx-amd64/testoutput/jdk_io/JTwork/java/io/BufferedInputStream >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> #section:script_messages >>>>>>>>>> ----------messages:(5/308)---------- >>>>>>>>>> JDK under test: >>>>>>>>>> (/Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/test/../build/macosx-x86_64-normal-server-release/images/j2sdk-image) >>>>>>>>>> >>>>>>>>>> openjdk version "1.8.0-internal" >>>>>>>>>> OpenJDK Runtime Environment (build >>>>>>>>>> 1.8.0-internal-icholas_2013_07_29_21_14-b00) >>>>>>>>>> OpenJDK 64-Bit Server VM (build 25.0-b42, mixed mode) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> #section:build >>>>>>>>>> ----------messages:(3/100)---------- >>>>>>>>>> command: build ReadAfterClose >>>>>>>>>> reason: Named class compiled on demand >>>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>>> >>>>>>>>>> #section:compile >>>>>>>>>> ----------messages:(3/235)---------- >>>>>>>>>> command: compile -XDignore.symbol.file=true >>>>>>>>>> /Users/Nicholas/Documents/OpenJDK/Projects/jdk8/jdk8/jdk/test/java/io/BufferedInputStream/ReadAfterClose.java >>>>>>>>>> >>>>>>>>>> reason: .class file out of date or does not exist >>>>>>>>>> elapsed time (seconds): 60.005 >>>>>>>>>> result: Error. Cannot get VM for test: >>>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test result: Error. Cannot get VM for test: >>>>>>>>>> java.net.SocketTimeoutException: Accept timed out >>>>>>>>>> >>>>> >>> > From jonathan.gibbons at oracle.com Thu Aug 8 09:22:09 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Aug 2013 09:22:09 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <5203C3C7.80503@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <5202F2E2.4000206@oracle.com> <5202F803.2050402@oracle.com> <52030383.5010203@oracle.com> <520314EF.2080200@oracle.com> <4E3B1671-55BC-4A76-8980-BE3E30B1FABD@oracle.com> <5203C0EE.3040804@oracle.com> <5203C3C7.80503@oracle.com> Message-ID: <5203C5B1.6080701@oracle.com> On 08/08/2013 09:13 AM, Chris Hegarty wrote: > > So we need a b07 of jtreg before we can proceed with this? > > -Chris. General question to all: How much will fall over if we call it 4.2? -- Jon From mike.duigou at oracle.com Thu Aug 8 09:36:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 8 Aug 2013 09:36:14 -0700 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <5203C5B1.6080701@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <5202F2E2.4000206@oracle.com> <5202F803.2050402@oracle.com> <52030383.5010203@oracle.com> <520314EF.2080200@oracle.com> <4E3B1671-55BC-4A76-8980-BE3E30B1FABD@oracle.com> <5203C0EE.3040804@oracle.com> <5203C3C7.80503@oracle.com> <5203C5B1.6080701@oracle.com> Message-ID: On 2013-08-08, at 9:22, Jonathan Gibbons wrote: > On 08/08/2013 09:13 AM, Chris Hegarty wrote: >> >> So we need a b07 of jtreg before we can proceed with this? >> >> -Chris. > > General question to all: > > How much will fall over if we call it 4.2? Some of the build scripts and makefies use 4.1 in SLASH_JAVA relative paths for default location. If we move to 4.2 it would be nice to add a current -> 4.2 link so that we don't have to fix it again ie scripts would use "current" rather than "4.2" > -- Jon From jonathan.gibbons at oracle.com Sun Aug 11 14:01:15 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 11 Aug 2013 14:01:15 -0700 Subject: New feature: rerun instructions Message-ID: <5207FB9B.90407@oracle.com> The following changeset provides an initial version of a new feature in jtreg, to provide a script to rerun a test. The intent is to make it simpler to run a test outside the jtreg harness. Although this is otherwise reasonably simple for standard "main program" tests, it may be less obvious to the uninitiated how to rerun JUnit and TestNG tests. http://hg.openjdk.java.net/code-tools/jtreg/rev/b9e916f66af3 As each action within a test is executed, a new block (labeled "rerun") is written into the .jtr file. This block contains one or more commands in bash syntax to more-or-less replicate the effect of the action outside the harness. If the test was being run in othervm mode, the commands should be reasonably accurate. If the test was being run in agentvm or samevm the commands will be more of an approximate, since there is no attempt the replicate the classloaders used by jtreg to run the test. Although there is no attempt to replicate class loaders, jtreg executes some classes via "wrapper classes". The use of these wrapper classes is included in the rerun script. Currently, the "rerun" blocks are enabled by default. This does mean that .jtr files are bigger as a result, and the block does appear in the output generated by -verbose:all. Given this, it may be desirable to make the presence of the "rerun" blocks optional. Within the .jtr file itself, the content of all blocks is encoded such that non-ASCII characters are encoded as \\u/xxxx/, and \ is encoded as \\. (This cannot reasonably be changed.) As a result, those commands in the rerun block which span multiple lines have the end-of-line \ encoded as \\. To extract the rerun commands, you can either cut and paste from the .jtr file (and fixup the \ characters) or you can use an experimental new jtreg command line option "-show:rerun /test-name/". The /test-name/ argument should be the name of a test within the test suite (not the name of a .jtr file.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20130811/972ca954/attachment.html From henry.jen at oracle.com Mon Aug 19 22:03:01 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 19 Aug 2013 22:03:01 -0700 Subject: bootclasspath.dir usage Message-ID: <5212F885.3010901@oracle.com> Hi, I try to move a test for Pattern.splitAsStream() into test/java/util/regex because that is where is should be based on convention. The test is now currently several layers under test/java/util/stream as initially developed in part of lambda testng tests. The move is not straightforward because it makes use of stream test framework which has to be included in bootclasspath. I added @library tag, and hopefully it picks up bootclasspath.dir setting from TEST.properties located in test/java/util/stream/bootlib/TEST/properties as that seems to be how stream tests works. This partially works. What I mean by that is, if I try to run regex test from a clean state, the bootclasspath is not picked up and the test failed as show in attached PatternTest.jtr.failed as you can see in the rerun section(a nice feature, BTW). However, if I run a stream test first and keep the JT* working folder, the test passes. Attached is the patch file, and you can reproduce this with following steps after apply attached JDK-8016846 for the test, $ cd jdk $ jtreg -v test/java/util/regex #failed $ jtreg -v test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java $ jtreg -v test/java/util/regex #succeeded or combine above two steps into one also work, $ jtreg -v test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java test/java/util/regex #succeeded Do I miss any option here or this is not really supported? Cheers, Henry -------------- next part -------------- # HG changeset patch # Parent 076ce07eaae7430d72222efc33722190234656be 8016846: Pattern.splitAsStream tests required Reviewed-by: Contributed-by: Ben Evans diff -r 076ce07eaae7 test/java/util/regex/PatternTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/regex/PatternTest.java Mon Aug 19 21:50:59 2013 -0700 @@ -0,0 +1,146 @@ +/* + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/** + * @test + * @summary Unit tests for wrapping classes should delegate to default methods + * @library /java/util/stream/bootlib + * @run testng/othervm PatternTest + */ + +import org.testng.annotations.DataProvider; +import org.testng.annotations.Test; + +import java.util.ArrayList; +import java.util.List; +import java.util.function.Supplier; +import java.util.regex.Pattern; +import java.util.stream.LambdaTestHelpers; +import java.util.stream.OpTestCase; +import java.util.stream.Stream; +import java.util.stream.TestData; + + at Test +public class PatternTest extends OpTestCase { + + @DataProvider(name = "Stream") + public static Object[][] makeStreamTestData() { + List data = new ArrayList<>(); + + String description = ""; + String input = "awgqwefg1fefw4vssv1vvv1"; + Pattern pattern = Pattern.compile("4"); + List expected = new ArrayList<>(); + expected.add("awgqwefg1fefw"); + expected.add("vssv1vvv1"); + + // Must match the type signature of the consumer of this data, testStrings + // String, String, Pattern, List + data.add(new Object[]{description, input, pattern, expected}); + + input = "afbfq\u00a3abgwgb\u00a3awngnwggw\u00a3a\u00a3ahjrnhneerh"; + pattern = Pattern.compile("\u00a3a"); + expected = new ArrayList<>(); + expected.add("afbfq"); + expected.add("bgwgb"); + expected.add("wngnwggw"); + expected.add(""); + expected.add("hjrnhneerh"); + + data.add(new Object[]{description, input, pattern, expected}); + + + input = "awgqwefg1fefw4vssv1vvv1"; + pattern = Pattern.compile("1"); + expected = new ArrayList<>(); + expected.add("awgqwefg"); + expected.add("fefw4vssv"); + expected.add("vvv"); + + data.add(new Object[]{description, input, pattern, expected}); + + + input = "a\u4ebafg1fefw\u4eba4\u9f9cvssv\u9f9c1v\u672c\u672cvv"; + pattern = Pattern.compile("1"); + expected = new ArrayList<>(); + expected.add("a\u4ebafg"); + expected.add("fefw\u4eba4\u9f9cvssv\u9f9c"); + expected.add("v\u672c\u672cvv"); + + data.add(new Object[]{description, input, pattern, expected}); + + + input = "1\u56da23\u56da456\u56da7890"; + pattern = Pattern.compile("\u56da"); + expected = new ArrayList<>(); + expected.add("1"); + expected.add("23"); + expected.add("456"); + expected.add("7890"); + + data.add(new Object[]{description, input, pattern, expected}); + + + input = "1\u56da23\u9f9c\u672c\u672c\u56da456\u56da\u9f9c\u672c7890"; + pattern = Pattern.compile("\u56da"); + expected = new ArrayList<>(); + expected.add("1"); + expected.add("23\u9f9c\u672c\u672c"); + expected.add("456"); + expected.add("\u9f9c\u672c7890"); + + data.add(new Object[]{description, input, pattern, expected}); + + + input = ""; + pattern = Pattern.compile("\u56da"); + expected = new ArrayList<>(); + + data.add(new Object[]{description, input, pattern, expected}); + + + description = "Multiple separators"; + input = "This is,testing: with\tdifferent separators."; + pattern = Pattern.compile("[ \t,:.]"); + expected = new ArrayList<>(); + expected.add("This"); + expected.add("is"); + expected.add("testing"); + expected.add(""); + expected.add("with"); + expected.add("different"); + expected.add("separators"); + + data.add(new Object[] {description, input, pattern, expected}); + return data.toArray(new Object[0][]); + } + + @Test(dataProvider = "Stream") + public void testStrings(String description, String input, Pattern pattern, List expected) { + Supplier> ss = () -> pattern.splitAsStream(input); + withData(TestData.Factory.ofSupplier(description, ss)) + .stream(LambdaTestHelpers.identity()) + .expectedResult(expected) + .exercise(); + } +} -------------- next part -------------- #Test Results (version 2) #Mon Aug 19 21:43:13 PDT 2013 #checksum:17a3cad0e0f9a452 #-----testdescription----- $file=/home/hjen/ws/tl-work/jdk/test/java/util/regex/PatternTest.java $root=/home/hjen/ws/tl-work/jdk/test keywords=othervm library=/java/util/stream/bootlib run=USER_SPECIFIED testng/othervm PatternTest\n source=PatternTest.java title=Unit tests for wrapping classes should delegate to default methods #-----environment----- #-----testresult----- description=file\:/home/hjen/ws/tl-work/jdk/test/java/util/regex/PatternTest.java elapsed=7625 0\:00\:07.625 end=Mon Aug 19 21\:43\:13 PDT 2013 environment=regtest execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.SecurityException\: Prohibited package name\: java.util.stream hostname=hjen-e6410 javatestOS=Linux 3.8.0-27-generic (amd64) javatestVersion=4.4 jtregVersion=jtreg 4.1 fcs b07 script=com.sun.javatest.regtest.RegressionScript sections=script_messages build compile testng start=Mon Aug 19 21\:43\:05 PDT 2013 test=java/util/regex/PatternTest.java user.name=hjen work=/home/hjen/ws/tl-work/jdk/JTwork/java/util/regex #section:script_messages ----------messages:(5/301)---------- JDK under test: (/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image) openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-hjen_2013_08_15_13_09-b00) OpenJDK 64-Bit Server VM (build 25.0-b45-fastdebug, mixed mode) #section:build ----------messages:(3/96)---------- command: build PatternTest reason: Named class compiled on demand elapsed time (seconds): 7.023 result: Passed. Build successful #section:compile ----------messages:(3/187)---------- command: compile -XDignore.symbol.file=true /home/hjen/ws/tl-work/jdk/test/java/util/regex/PatternTest.java reason: .class file out of date or does not exist elapsed time (seconds): 7.01 ----------rerun:(16/1596)*---------- DISPLAY=:0 \\ HOME=/home/hjen \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/javac \\ -J-Dtest.vm.opts= \\ -J-Dcompile.jdk=/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image \\ -J-Dtest.src.path=/home/hjen/ws/tl-work/jdk/test/java/util/regex:/home/hjen/ws/tl-work/jdk/test/java/util/stream/bootlib \\ -J-Dtest.src=/home/hjen/ws/tl-work/jdk/test/java/util/regex \\ -J-Dtest.tool.vm.opts= \\ -J-Dtest.class.path=/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex:/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/stream/bootlib \\ -J-Dtest.classes=/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex \\ -J-Dtest.jdk=/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image \\ -J-Dtest.java.opts= \\ -J-Dtest.compiler.opts= \\ -d /home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex -classpath /home/hjen/jdk-tools/jtreg/lib/javatest.jar:/home/hjen/jdk-tools/jtreg/lib/jtreg.jar:/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex:/home/hjen/ws/tl-work/jdk/test/java/util/regex:/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/lib/tools.jar:/home/hjen/jdk-tools/jtreg/lib/testng.jar -sourcepath /home/hjen/ws/tl-work/jdk/test/java/util/regex:/home/hjen/ws/tl-work/jdk/test/java/util/stream/bootlib -XDignore.symbol.file=true /home/hjen/ws/tl-work/jdk/test/java/util/regex/PatternTest.java ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:testng ----------messages:(3/121)---------- command: testng PatternTest reason: User specified action: run testng/othervm PatternTest elapsed time (seconds): 0.302 ----------System.out:(0/0)---------- ----------System.err:(40/2489)---------- java.lang.SecurityException: Prohibited package name: java.util.stream at java.lang.ClassLoader.preDefineClass(ClassLoader.java:651) at java.lang.ClassLoader.defineClass(ClassLoader.java:750) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:448) at java.net.URLClassLoader.access$100(URLClassLoader.java:70) at java.net.URLClassLoader$1.run(URLClassLoader.java:360) at java.net.URLClassLoader$1.run(URLClassLoader.java:354) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:353) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:752) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:448) at java.net.URLClassLoader.access$100(URLClassLoader.java:70) at java.net.URLClassLoader$1.run(URLClassLoader.java:360) at java.net.URLClassLoader$1.run(URLClassLoader.java:354) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:353) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:258) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:151) at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:143) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:724) JavaTest Message: Test threw exception: java.lang.SecurityException: Prohibited package name: java.util.stream JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.SecurityException: Prohibited package name: java.util.stream ----------rerun:(17/1466)*---------- DISPLAY=:0 \\ HOME=/home/hjen \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/home/hjen/jdk-tools/jtreg/lib/javatest.jar:/home/hjen/jdk-tools/jtreg/lib/jtreg.jar:/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex:/home/hjen/ws/tl-work/jdk/test/java/util/regex:/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/lib/tools.jar:/home/hjen/jdk-tools/jtreg/lib/testng.jar \\ /home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java \\ -Dtest.vm.opts= \\ -Dcompile.jdk=/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image \\ -Dtest.src.path=/home/hjen/ws/tl-work/jdk/test/java/util/regex:/home/hjen/ws/tl-work/jdk/test/java/util/stream/bootlib \\ -Dtest.src=/home/hjen/ws/tl-work/jdk/test/java/util/regex \\ -Dtest.tool.vm.opts= \\ -Dtest.class.path=/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex:/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/stream/bootlib \\ -Dtest.classes=/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex \\ -Dtest.jdk=/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image \\ -Dtest.java.opts= \\ -Dtest.compiler.opts= \\ com.sun.javatest.regtest.MainWrapper /home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex/PatternTest.jta java/util/regex/PatternTest.java PatternTest result: Failed. Execution failed: `main' threw exception: java.lang.SecurityException: Prohibited package name: java.util.stream test result: Failed. Execution failed: `main' threw exception: java.lang.SecurityException: Prohibited package name: java.util.stream -------------- next part -------------- #Test Results (version 2) #Mon Aug 19 21:44:45 PDT 2013 #checksum:67d5e66434b0a397 #-----testdescription----- $file=/home/hjen/ws/tl-work/jdk/test/java/util/regex/PatternTest.java $root=/home/hjen/ws/tl-work/jdk/test keywords=othervm library=/java/util/stream/bootlib run=USER_SPECIFIED testng/othervm PatternTest\n source=PatternTest.java title=Unit tests for wrapping classes should delegate to default methods #-----environment----- #-----testresult----- description=file\:/home/hjen/ws/tl-work/jdk/test/java/util/regex/PatternTest.java elapsed=1945 0\:00\:01.945 end=Mon Aug 19 21\:44\:45 PDT 2013 environment=regtest execStatus=Passed. Execution successful hostname=hjen-e6410 javatestOS=Linux 3.8.0-27-generic (amd64) javatestVersion=4.4 jtregVersion=jtreg 4.1 fcs b07 script=com.sun.javatest.regtest.RegressionScript sections=script_messages build testng start=Mon Aug 19 21\:44\:43 PDT 2013 test=java/util/regex/PatternTest.java user.name=hjen work=/home/hjen/ws/tl-work/jdk/JTwork/java/util/regex #section:script_messages ----------messages:(5/301)---------- JDK under test: (/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image) openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-hjen_2013_08_15_13_09-b00) OpenJDK 64-Bit Server VM (build 25.0-b45-fastdebug, mixed mode) #section:build ----------messages:(3/96)---------- command: build PatternTest reason: Named class compiled on demand elapsed time (seconds): 0.002 result: Passed. All files up to date #section:testng ----------messages:(3/121)---------- command: testng PatternTest reason: User specified action: run testng/othervm PatternTest elapsed time (seconds): 1.653 ----------System.out:(41/3646)*---------- [TestNG] Running: java/util/regex/PatternTest.java config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("", "awgqwefg1fefw4vssv1vvv1", 4, [awgqwefg1fefw, vssv1vvv1]): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("", "afbfq\u00a3abgwgb\u00a3awngnwggw\u00a3a\u00a3ahjrnhneerh", \u00a3a, [afbfq, bgwgb, wngnwggw, , hjrnhneerh]): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("", "awgqwefg1fefw4vssv1vvv1", 1, [awgqwefg, fefw4vssv, vvv]): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("", "a\u4ebafg1fefw\u4eba4\u9f9cvssv\u9f9c1v\u672c\u672cvv", 1, [a\u4ebafg, fefw\u4eba4\u9f9cvssv\u9f9c, v\u672c\u672cvv]): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("", "1\u56da23\u56da456\u56da7890", \u56da, [1, 23, 456, 7890]): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("", "1\u56da23\u9f9c\u672c\u672c\u56da456\u56da\u9f9c\u672c7890", \u56da, [1, 23\u9f9c\u672c\u672c, 456, \u9f9c\u672c7890]): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("", "", \u56da, []): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success config java.util.stream.LoggingTestCase.before(): success test PatternTest.testStrings("Multiple separators", "This is,testing: with different separators.", [ ,:.], [This, is, testing, , with, different, separators]): success config java.util.stream.LoggingTestCase.after([TestResult: testStrings STATUS:SUCCESS METHOD:PatternTest.testStrings(java.lang.String, java.lang.String, java.util.regex.Pattern, java.util.List)[pri:0, instance:PatternTest at 325d5142]] ): success =============================================== java/util/regex/PatternTest.java Total tests run: 8, Failures: 0, Skips: 0 =============================================== ----------System.err:(1/15)---------- STATUS:Passed. ----------rerun:(18/1561)*---------- DISPLAY=:0 \\ HOME=/home/hjen \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/home/hjen/jdk-tools/jtreg/lib/javatest.jar:/home/hjen/jdk-tools/jtreg/lib/jtreg.jar:/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex:/home/hjen/ws/tl-work/jdk/test/java/util/regex:/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/lib/tools.jar \\ /home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java \\ -Dtest.vm.opts= \\ -Dcompile.jdk=/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image \\ -Dtest.src.path=/home/hjen/ws/tl-work/jdk/test/java/util/regex:/home/hjen/ws/tl-work/jdk/test/java/util/stream/bootlib \\ -Dtest.src=/home/hjen/ws/tl-work/jdk/test/java/util/regex \\ -Dtest.tool.vm.opts= \\ -Dtest.class.path=/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex:/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/stream/bootlib \\ -Dtest.classes=/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex \\ -Dtest.jdk=/home/hjen/ws/lambda/work/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image \\ -Dtest.java.opts= \\ -Dtest.compiler.opts= \\ -Xbootclasspath/a:/home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/stream/bootlib:/home/hjen/jdk-tools/jtreg/lib/testng.jar \\ com.sun.javatest.regtest.MainWrapper /home/hjen/ws/tl-work/jdk/JTwork/classes/java/util/regex/PatternTest.jta java/util/regex/PatternTest.java PatternTest result: Passed. Execution successful test result: Passed. Execution successful From david.holmes at oracle.com Mon Aug 19 22:20:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Aug 2013 15:20:17 +1000 Subject: bootclasspath.dir usage In-Reply-To: <5212F885.3010901@oracle.com> References: <5212F885.3010901@oracle.com> Message-ID: <5212FC91.4080500@oracle.com> Henry, I'm no expert but I think this: + * @library /java/util/stream/bootlib needs to be a relative path to the current test. David On 20/08/2013 3:03 PM, Henry Jen wrote: > Hi, > > I try to move a test for Pattern.splitAsStream() into > test/java/util/regex because that is where is should be based on > convention. The test is now currently several layers under > test/java/util/stream as initially developed in part of lambda testng tests. > > The move is not straightforward because it makes use of stream test > framework which has to be included in bootclasspath. > > I added @library tag, and hopefully it picks up bootclasspath.dir > setting from TEST.properties located in > test/java/util/stream/bootlib/TEST/properties as that seems to be how > stream tests works. > > This partially works. What I mean by that is, if I try to run regex test > from a clean state, the bootclasspath is not picked up and the test > failed as show in attached PatternTest.jtr.failed as you can see in the > rerun section(a nice feature, BTW). > > However, if I run a stream test first and keep the JT* working folder, > the test passes. Attached is the patch file, and you can reproduce this > with following steps after apply attached JDK-8016846 for the test, > > $ cd jdk > $ jtreg -v test/java/util/regex #failed > $ jtreg -v > test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java > $ jtreg -v test/java/util/regex #succeeded > > or combine above two steps into one also work, > > $ jtreg -v > test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java > test/java/util/regex #succeeded > > Do I miss any option here or this is not really supported? > > Cheers, > Henry > From henry.jen at oracle.com Mon Aug 19 22:33:53 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 19 Aug 2013 22:33:53 -0700 Subject: bootclasspath.dir usage In-Reply-To: <5212FC91.4080500@oracle.com> References: <5212F885.3010901@oracle.com> <5212FC91.4080500@oracle.com> Message-ID: <301FB3B9-C276-4EB1-AA2A-3470C3C1ED85@oracle.com> On Aug 19, 2013, at 10:20 PM, David Holmes wrote: > Henry, > > I'm no expert but I think this: > > + * @library /java/util/stream/bootlib > > needs to be a relative path to the current test. > Thanks for the idea, David. My understanding is that jtreg will find TEST.root to locate the root folder, this seems to be working fine based on the result. But I cannot tell if this is relative new feature as introduced with testng support. Cheers, Henry From david.holmes at oracle.com Mon Aug 19 22:53:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Aug 2013 15:53:42 +1000 Subject: bootclasspath.dir usage In-Reply-To: <301FB3B9-C276-4EB1-AA2A-3470C3C1ED85@oracle.com> References: <5212F885.3010901@oracle.com> <5212FC91.4080500@oracle.com> <301FB3B9-C276-4EB1-AA2A-3470C3C1ED85@oracle.com> Message-ID: <52130466.7090903@oracle.com> On 20/08/2013 3:33 PM, Henry Jen wrote: > On Aug 19, 2013, at 10:20 PM, David Holmes wrote: > >> Henry, >> >> I'm no expert but I think this: >> >> + * @library /java/util/stream/bootlib >> >> needs to be a relative path to the current test. >> > > Thanks for the idea, David. > > My understanding is that jtreg will find TEST.root to locate the root folder, this seems to be working fine based on the result. But I cannot tell if this is relative new feature as introduced with testng support. The folder with TEST.ROOT is the root folder by definition. I see around 1000 existing @library usages all of which use a relative path :) Cheers, David > Cheers, > Henry > From david.holmes at oracle.com Tue Aug 20 00:04:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Aug 2013 17:04:14 +1000 Subject: Minor bug ? Message-ID: <521314EE.2080006@oracle.com> Running the JDK test suite I see: runner starting test: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh runner finished test: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh Error. Parse Exception: `@library' must appear before first `@run' but the test contains: # @test # @ignore until 6543856 is fixed # @bug 4990825 # @summary attach to external but local JVM processes # @library ../../testlibrary # @build Sleeper # @build JavaProcess # @build MonitorVmStartTerminate # @run shell MonitorVmStartTerminate.sh I would guess that the @ignore might the problem. David From jonathan.gibbons at oracle.com Tue Aug 20 06:30:07 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Aug 2013 06:30:07 -0700 Subject: bootclasspath.dir usage In-Reply-To: <5212FC91.4080500@oracle.com> References: <5212F885.3010901@oracle.com> <5212FC91.4080500@oracle.com> Message-ID: <52136F5F.5080108@oracle.com> On 08/19/2013 10:20 PM, David Holmes wrote: > Henry, > > I'm no expert but I think this: > > + * @library /java/util/stream/bootlib > > needs to be a relative path to the current test. > > David David, Paths beginning "/" are evaluated relative to the test suite root directory. -- Jon From jonathan.gibbons at oracle.com Tue Aug 20 06:32:41 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Aug 2013 06:32:41 -0700 Subject: bootclasspath.dir usage In-Reply-To: <52130466.7090903@oracle.com> References: <5212F885.3010901@oracle.com> <5212FC91.4080500@oracle.com> <301FB3B9-C276-4EB1-AA2A-3470C3C1ED85@oracle.com> <52130466.7090903@oracle.com> Message-ID: <52136FF9.8070409@oracle.com> On 08/19/2013 10:53 PM, David Holmes wrote: > > I see around 1000 existing @library usages all of which use a relative > path :) > > Cheers, > David The support for test-root-relative paths is relatively recent. (sic.) Relative paths are evaluated relative to the containing directory. Absolute paths are evaluated relative to the test suite root directory. -- Jon From jonathan.gibbons at oracle.com Tue Aug 20 06:33:30 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Aug 2013 06:33:30 -0700 Subject: Minor bug ? In-Reply-To: <521314EE.2080006@oracle.com> References: <521314EE.2080006@oracle.com> Message-ID: <5213702A.3060909@oracle.com> On 08/20/2013 12:04 AM, David Holmes wrote: > Running the JDK test suite I see: > > runner starting test: > sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh > runner finished test: > sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh > Error. Parse Exception: `@library' must appear before first `@run' > > > but the test contains: > > # @test > # @ignore until 6543856 is fixed > # @bug 4990825 > # @summary attach to external but local JVM processes > # @library ../../testlibrary > # @build Sleeper > # @build JavaProcess > # @build MonitorVmStartTerminate > # @run shell MonitorVmStartTerminate.sh > > I would guess that the @ignore might the problem. > > David Yes, you need to move the @ignore down after @library. -- Jon From jonathan.gibbons at oracle.com Tue Aug 20 12:55:33 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Aug 2013 12:55:33 -0700 Subject: bootclasspath.dir usage In-Reply-To: <5212F885.3010901@oracle.com> References: <5212F885.3010901@oracle.com> Message-ID: <5213C9B5.20703@oracle.com> Henry, It sounds like you have insufficient @build directives and that some of your library classes are being implicitly compiled (into the wrong place) -- Jon On 08/19/2013 10:03 PM, Henry Jen wrote: > Hi, > > I try to move a test for Pattern.splitAsStream() into > test/java/util/regex because that is where is should be based on > convention. The test is now currently several layers under > test/java/util/stream as initially developed in part of lambda testng tests. > > The move is not straightforward because it makes use of stream test > framework which has to be included in bootclasspath. > > I added @library tag, and hopefully it picks up bootclasspath.dir > setting from TEST.properties located in > test/java/util/stream/bootlib/TEST/properties as that seems to be how > stream tests works. > > This partially works. What I mean by that is, if I try to run regex test > from a clean state, the bootclasspath is not picked up and the test > failed as show in attached PatternTest.jtr.failed as you can see in the > rerun section(a nice feature, BTW). > > However, if I run a stream test first and keep the JT* working folder, > the test passes. Attached is the patch file, and you can reproduce this > with following steps after apply attached JDK-8016846 for the test, > > $ cd jdk > $ jtreg -v test/java/util/regex #failed > $ jtreg -v > test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java > $ jtreg -v test/java/util/regex #succeeded > > or combine above two steps into one also work, > > $ jtreg -v > test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java > test/java/util/regex #succeeded > > Do I miss any option here or this is not really supported? > > Cheers, > Henry From jonathan.gibbons at oracle.com Tue Aug 20 13:15:40 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Aug 2013 13:15:40 -0700 Subject: bootclasspath.dir usage In-Reply-To: <5213C9B5.20703@oracle.com> References: <5212F885.3010901@oracle.com> <5213C9B5.20703@oracle.com> Message-ID: <5213CE6C.1090802@oracle.com> Henry, Start with a clean work directory and try to run the test. Now look at *all* of JTwork/classes and see if you can see any .class files that seem to be in the wrong directory. Make sure those classes are mentioned in explicit @build directives in the right place. Failing that, do the following: Identify two tests, I'll call them A and B, such that B is the test that sometimes fails, and A is a test that allows B to pass if you run it first. 1. Clean your work directory. Run test B (the test that will fail.) Run test A (in a separate jtreg run) Execute 'cd JTWork ; find . classes -type f > LIST-B-A.txt 2. Start over. Clean your work directory Run test A first this time Run test B (which should pas this time) Execute 'cd JTWork ; find . classes -type f > LIST-A-B.txt Compare the two LIST-*.txt files and try and identify the reason for the differences. -- Jon On 08/20/2013 12:55 PM, Jonathan Gibbons wrote: > Henry, > > It sounds like you have insufficient @build directives and that some > of your library classes are being implicitly compiled (into the wrong > place) > > -- Jon > > On 08/19/2013 10:03 PM, Henry Jen wrote: >> Hi, >> >> I try to move a test for Pattern.splitAsStream() into >> test/java/util/regex because that is where is should be based on >> convention. The test is now currently several layers under >> test/java/util/stream as initially developed in part of lambda testng >> tests. >> >> The move is not straightforward because it makes use of stream test >> framework which has to be included in bootclasspath. >> >> I added @library tag, and hopefully it picks up bootclasspath.dir >> setting from TEST.properties located in >> test/java/util/stream/bootlib/TEST/properties as that seems to be how >> stream tests works. >> >> This partially works. What I mean by that is, if I try to run regex test >> from a clean state, the bootclasspath is not picked up and the test >> failed as show in attached PatternTest.jtr.failed as you can see in the >> rerun section(a nice feature, BTW). >> >> However, if I run a stream test first and keep the JT* working folder, >> the test passes. Attached is the patch file, and you can reproduce this >> with following steps after apply attached JDK-8016846 for the test, >> >> $ cd jdk >> $ jtreg -v test/java/util/regex #failed >> $ jtreg -v >> test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java >> >> $ jtreg -v test/java/util/regex #succeeded >> >> or combine above two steps into one also work, >> >> $ jtreg -v >> test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java >> >> test/java/util/regex #succeeded >> >> Do I miss any option here or this is not really supported? >> >> Cheers, >> Henry > From henry.jen at oracle.com Tue Aug 20 14:21:12 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 20 Aug 2013 14:21:12 -0700 Subject: bootclasspath.dir usage In-Reply-To: <5213C9B5.20703@oracle.com> References: <5212F885.3010901@oracle.com> <5213C9B5.20703@oracle.com> Message-ID: <5213DDC8.1040706@oracle.com> On 08/20/2013 12:55 PM, Jonathan Gibbons wrote: > Henry, > > It sounds like you have insufficient @build directives and that some of > your library classes are being implicitly compiled (into the wrong place) > Thanks Jon for the detailed instruction, you are right about this, it's because the bootlib is build into the folder where test resides. After add build tag to initiate build library first, they appear in the correct folder and the test pass. Luckily one class is enough to cover all other classes the test depends on in that bootlib(I removed extra after review the .jtr report, not sure if this is a good idea or I should leave whatever class I will import on the @build tag). @build java.util.stream.OpTestCase Is this by design? I thought path referenced in @library is to be built from that folder. Cheers, Henry From jonathan.gibbons at oracle.com Tue Aug 20 14:38:53 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Aug 2013 14:38:53 -0700 Subject: bootclasspath.dir usage In-Reply-To: <5213DDC8.1040706@oracle.com> References: <5212F885.3010901@oracle.com> <5213C9B5.20703@oracle.com> <5213DDC8.1040706@oracle.com> Message-ID: <5213E1ED.4030104@oracle.com> On 08/20/2013 02:21 PM, Henry Jen wrote: > On 08/20/2013 12:55 PM, Jonathan Gibbons wrote: >> Henry, >> >> It sounds like you have insufficient @build directives and that some of >> your library classes are being implicitly compiled (into the wrong place) >> > Thanks Jon for the detailed instruction, you are right about this, it's > because the bootlib is build into the folder where test resides. > > After add build tag to initiate build library first, they appear in the > correct folder and the test pass. Luckily one class is enough to cover > all other classes the test depends on in that bootlib(I removed extra > after review the .jtr report, not sure if this is a good idea or I > should leave whatever class I will import on the @build tag). > > @build java.util.stream.OpTestCase > > Is this by design? I thought path referenced in @library is to be built > from that folder. > > Cheers, > Henry > The problem comes with implicit compilation. jtreg is clever enough to know what sources come from which library directory, but it is /not/ clever enough (and is not supposed to be) to look inside the library source code and see what code it references _from other libraries_. If you tell jtreg to build those other classes explicitly, you will end up with class files "in the right place". But if end up with some files being implicitly compiled, then you risk them ending up in the same place that explicitly compiled files are going. -- Jon From aleksey.shipilev at oracle.com Wed Aug 21 11:37:13 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 21 Aug 2013 22:37:13 +0400 Subject: jtreg test case for failing VM option? Message-ID: <521508D9.5070406@oracle.com> Hi, I want to write the test for the failing VM option, i.e. write the test for acceptable ranges for particular option. This is the test I have in hand: /* * @test * @bug 8006997 * @summary ContendedPaddingWidth should be range-checked * * @run main/othervm/fail -XX:-RestrictContended -XX:ContendedPaddingWidth=-1 Options */ public class Options { public static void main(String[] args) throws Exception { System.out.println("Test PASSES"); } } I was tempted to think /fail will invert the behavior for the test, and if VM exits with non-zero exit code, it counts the test as passed. However, jtreg marks this test as failed, because: ----------System.err:(4/215)---------- ContendedPaddingWidth=-1 must be the between 0 and 8192 ContendedPaddingWidth=-1 must be the multiple of 8 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. result: Failed. Unexpected exit from test [exit code: 1] Is there a proper way to make the test like this? -Aleksey. From jonathan.gibbons at oracle.com Wed Aug 21 12:56:36 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 21 Aug 2013 12:56:36 -0700 Subject: jtreg test case for failing VM option? In-Reply-To: <521508D9.5070406@oracle.com> References: <521508D9.5070406@oracle.com> Message-ID: <52151B74.8080706@oracle.com> Write a /samevm test to exec a VM and check for the desired failure mode. -- Jon On 08/21/2013 11:37 AM, Aleksey Shipilev wrote: > Hi, > > I want to write the test for the failing VM option, i.e. write the test > for acceptable ranges for particular option. This is the test I have in > hand: > > /* > * @test > * @bug 8006997 > * @summary ContendedPaddingWidth should be range-checked > * > * @run main/othervm/fail -XX:-RestrictContended > -XX:ContendedPaddingWidth=-1 Options > */ > public class Options { > public static void main(String[] args) throws Exception { > System.out.println("Test PASSES"); > } > } > > I was tempted to think /fail will invert the behavior for the test, and > if VM exits with non-zero exit code, it counts the test as passed. > However, jtreg marks this test as failed, because: > > ----------System.err:(4/215)---------- > ContendedPaddingWidth=-1 must be the between 0 and 8192 > ContendedPaddingWidth=-1 must be the multiple of 8 > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > result: Failed. Unexpected exit from test [exit code: 1] > > Is there a proper way to make the test like this? > > -Aleksey. From jonathan.gibbons at oracle.com Wed Aug 21 13:38:24 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 21 Aug 2013 13:38:24 -0700 Subject: jtreg test case for failing VM option? In-Reply-To: <52151B74.8080706@oracle.com> References: <521508D9.5070406@oracle.com> <52151B74.8080706@oracle.com> Message-ID: <52152540.8080106@oracle.com> In general, using /fail is a very weak test and can lead to false positives, since *any* failure could cause the test to appear to succeed. In general, you'll do better to write a test that explicitly tests for the expected failure mode, and only fails if that is not found. -- Jon On 08/21/2013 12:56 PM, Jonathan Gibbons wrote: > Write a /samevm test to exec a VM and check for the desired failure mode. > > -- Jon > > > On 08/21/2013 11:37 AM, Aleksey Shipilev wrote: >> Hi, >> >> I want to write the test for the failing VM option, i.e. write the test >> for acceptable ranges for particular option. This is the test I have in >> hand: >> >> /* >> * @test >> * @bug 8006997 >> * @summary ContendedPaddingWidth should be range-checked >> * >> * @run main/othervm/fail -XX:-RestrictContended >> -XX:ContendedPaddingWidth=-1 Options >> */ >> public class Options { >> public static void main(String[] args) throws Exception { >> System.out.println("Test PASSES"); >> } >> } >> >> I was tempted to think /fail will invert the behavior for the test, and >> if VM exits with non-zero exit code, it counts the test as passed. >> However, jtreg marks this test as failed, because: >> >> ----------System.err:(4/215)---------- >> ContendedPaddingWidth=-1 must be the between 0 and 8192 >> ContendedPaddingWidth=-1 must be the multiple of 8 >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> result: Failed. Unexpected exit from test [exit code: 1] >> >> Is there a proper way to make the test like this? >> >> -Aleksey. > From weijun.wang at oracle.com Thu Aug 22 02:42:57 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 22 Aug 2013 17:42:57 +0800 Subject: doc for TEST.properties Message-ID: <5215DD21.1010709@oracle.com> Where can I find a doc for all supported keys in a TEST.properties file? Thanks Max From jonathan.gibbons at oracle.com Thu Aug 22 06:17:06 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 22 Aug 2013 06:17:06 -0700 Subject: doc for TEST.properties In-Reply-To: <5215DD21.1010709@oracle.com> References: <5215DD21.1010709@oracle.com> Message-ID: <52160F52.6020808@oracle.com> On 08/22/2013 02:42 AM, Weijun Wang wrote: > Where can I find a doc for all supported keys in a TEST.properties file? > > Thanks > Max Regrettably, that is still on my list. I'll bump up the proirity. -- Jon From aleksey.shipilev at oracle.com Fri Aug 23 04:18:54 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 23 Aug 2013 15:18:54 +0400 Subject: jtreg test case for failing VM option? In-Reply-To: <52152540.8080106@oracle.com> References: <521508D9.5070406@oracle.com> <52151B74.8080706@oracle.com> <52152540.8080106@oracle.com> Message-ID: <5217451E.5070707@oracle.com> Uhgm. So the answer is to use testlibrary/ProcessBuilder to invoke VM. Thanks! -Aleksey. On 08/22/2013 12:38 AM, Jonathan Gibbons wrote: > In general, using /fail is a very weak test and can lead to false > positives, > since *any* failure could cause the test to appear to succeed. In general, > you'll do better to write a test that explicitly tests for the expected > failure > mode, and only fails if that is not found. > > -- Jon > > > On 08/21/2013 12:56 PM, Jonathan Gibbons wrote: >> Write a /samevm test to exec a VM and check for the desired failure mode. >> >> -- Jon >> >> >> On 08/21/2013 11:37 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> I want to write the test for the failing VM option, i.e. write the test >>> for acceptable ranges for particular option. This is the test I have in >>> hand: >>> >>> /* >>> * @test >>> * @bug 8006997 >>> * @summary ContendedPaddingWidth should be range-checked >>> * >>> * @run main/othervm/fail -XX:-RestrictContended >>> -XX:ContendedPaddingWidth=-1 Options >>> */ >>> public class Options { >>> public static void main(String[] args) throws Exception { >>> System.out.println("Test PASSES"); >>> } >>> } >>> >>> I was tempted to think /fail will invert the behavior for the test, and >>> if VM exits with non-zero exit code, it counts the test as passed. >>> However, jtreg marks this test as failed, because: >>> >>> ----------System.err:(4/215)---------- >>> ContendedPaddingWidth=-1 must be the between 0 and 8192 >>> ContendedPaddingWidth=-1 must be the multiple of 8 >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> result: Failed. Unexpected exit from test [exit code: 1] >>> >>> Is there a proper way to make the test like this? >>> >>> -Aleksey. >> > From jonathan.gibbons at oracle.com Fri Aug 23 06:22:42 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 23 Aug 2013 06:22:42 -0700 Subject: jtreg test case for failing VM option? In-Reply-To: <5217451E.5070707@oracle.com> References: <521508D9.5070406@oracle.com> <52151B74.8080706@oracle.com> <52152540.8080106@oracle.com> <5217451E.5070707@oracle.com> Message-ID: <52176222.8080702@oracle.com> Yes. -- Jon On 08/23/2013 04:18 AM, Aleksey Shipilev wrote: > Uhgm. So the answer is to use testlibrary/ProcessBuilder to invoke VM. > > Thanks! > -Aleksey. > > On 08/22/2013 12:38 AM, Jonathan Gibbons wrote: >> In general, using /fail is a very weak test and can lead to false >> positives, >> since *any* failure could cause the test to appear to succeed. In general, >> you'll do better to write a test that explicitly tests for the expected >> failure >> mode, and only fails if that is not found. >> >> -- Jon >> >> >> On 08/21/2013 12:56 PM, Jonathan Gibbons wrote: >>> Write a /samevm test to exec a VM and check for the desired failure mode. >>> >>> -- Jon >>> >>> >>> On 08/21/2013 11:37 AM, Aleksey Shipilev wrote: >>>> Hi, >>>> >>>> I want to write the test for the failing VM option, i.e. write the test >>>> for acceptable ranges for particular option. This is the test I have in >>>> hand: >>>> >>>> /* >>>> * @test >>>> * @bug 8006997 >>>> * @summary ContendedPaddingWidth should be range-checked >>>> * >>>> * @run main/othervm/fail -XX:-RestrictContended >>>> -XX:ContendedPaddingWidth=-1 Options >>>> */ >>>> public class Options { >>>> public static void main(String[] args) throws Exception { >>>> System.out.println("Test PASSES"); >>>> } >>>> } >>>> >>>> I was tempted to think /fail will invert the behavior for the test, and >>>> if VM exits with non-zero exit code, it counts the test as passed. >>>> However, jtreg marks this test as failed, because: >>>> >>>> ----------System.err:(4/215)---------- >>>> ContendedPaddingWidth=-1 must be the between 0 and 8192 >>>> ContendedPaddingWidth=-1 must be the multiple of 8 >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> result: Failed. Unexpected exit from test [exit code: 1] >>>> >>>> Is there a proper way to make the test like this? >>>> >>>> -Aleksey. From stuart.marks at oracle.com Fri Aug 23 09:21:24 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 23 Aug 2013 09:21:24 -0700 Subject: jtreg test case for failing VM option? In-Reply-To: <5217451E.5070707@oracle.com> References: <521508D9.5070406@oracle.com> <52151B74.8080706@oracle.com> <52152540.8080106@oracle.com> <5217451E.5070707@oracle.com> Message-ID: <52178C04.5080800@oracle.com> Hi, yes, this is probably as much of a test of the testlibrary as anything. It should be about two lines of code to do what you want. If it isn't, then the testlibrary needs work! Let us know. s'marks On 8/23/13 4:18 AM, Aleksey Shipilev wrote: > Uhgm. So the answer is to use testlibrary/ProcessBuilder to invoke VM. > > Thanks! > -Aleksey. > > On 08/22/2013 12:38 AM, Jonathan Gibbons wrote: >> In general, using /fail is a very weak test and can lead to false >> positives, >> since *any* failure could cause the test to appear to succeed. In general, >> you'll do better to write a test that explicitly tests for the expected >> failure >> mode, and only fails if that is not found. >> >> -- Jon >> >> >> On 08/21/2013 12:56 PM, Jonathan Gibbons wrote: >>> Write a /samevm test to exec a VM and check for the desired failure mode. >>> >>> -- Jon >>> >>> >>> On 08/21/2013 11:37 AM, Aleksey Shipilev wrote: >>>> Hi, >>>> >>>> I want to write the test for the failing VM option, i.e. write the test >>>> for acceptable ranges for particular option. This is the test I have in >>>> hand: >>>> >>>> /* >>>> * @test >>>> * @bug 8006997 >>>> * @summary ContendedPaddingWidth should be range-checked >>>> * >>>> * @run main/othervm/fail -XX:-RestrictContended >>>> -XX:ContendedPaddingWidth=-1 Options >>>> */ >>>> public class Options { >>>> public static void main(String[] args) throws Exception { >>>> System.out.println("Test PASSES"); >>>> } >>>> } >>>> >>>> I was tempted to think /fail will invert the behavior for the test, and >>>> if VM exits with non-zero exit code, it counts the test as passed. >>>> However, jtreg marks this test as failed, because: >>>> >>>> ----------System.err:(4/215)---------- >>>> ContendedPaddingWidth=-1 must be the between 0 and 8192 >>>> ContendedPaddingWidth=-1 must be the multiple of 8 >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> result: Failed. Unexpected exit from test [exit code: 1] >>>> >>>> Is there a proper way to make the test like this? >>>> >>>> -Aleksey. >>> >> > From aleksey.shipilev at oracle.com Fri Aug 23 09:45:15 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 23 Aug 2013 20:45:15 +0400 Subject: jtreg test case for failing VM option? In-Reply-To: <52178C04.5080800@oracle.com> References: <521508D9.5070406@oracle.com> <52151B74.8080706@oracle.com> <52152540.8080106@oracle.com> <5217451E.5070707@oracle.com> <52178C04.5080800@oracle.com> Message-ID: <5217919B.6070108@oracle.com> On 08/23/2013 08:21 PM, Stuart Marks wrote: > Hi, yes, this is probably as much of a test of the testlibrary as > anything. It should be about two lines of code to do what you want. If > it isn't, then the testlibrary needs work! API seems OK to me: http://cr.openjdk.java.net/~shade/8023638/webrev.00/hotspot/test/runtime/contended/Options.java.html Good stuff! -Aleksey. From stuart.marks at oracle.com Fri Aug 23 11:03:06 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 23 Aug 2013 11:03:06 -0700 Subject: jtreg test case for failing VM option? In-Reply-To: <5217919B.6070108@oracle.com> References: <521508D9.5070406@oracle.com> <52151B74.8080706@oracle.com> <52152540.8080106@oracle.com> <5217451E.5070707@oracle.com> <52178C04.5080800@oracle.com> <5217919B.6070108@oracle.com> Message-ID: <5217A3DA.5060707@oracle.com> On 8/23/13 9:45 AM, Aleksey Shipilev wrote: > On 08/23/2013 08:21 PM, Stuart Marks wrote: >> Hi, yes, this is probably as much of a test of the testlibrary as >> anything. It should be about two lines of code to do what you want. If >> it isn't, then the testlibrary needs work! > > API seems OK to me: > http://cr.openjdk.java.net/~shade/8023638/webrev.00/hotspot/test/runtime/contended/Options.java.html > > Good stuff! Ah, you're in hotspot. Yes, looks good, and in fact this is exactly the intended use of this test library. See similar tests in hotspot/test/gc/startup_warnings if you haven't already. There is a small style point about whether these should be all one test or individual tests. The GC startup tests I mention above are all individual tests. Personally I think it's a lot of boilerplate to make them all individual tests, but the hotspot reviewers may think otherwise. s'marks From patrick.zhang at oracle.com Wed Aug 21 03:47:31 2013 From: patrick.zhang at oracle.com (patrick zhang) Date: Wed, 21 Aug 2013 10:47:31 -0000 Subject: some questions for TestNG support in Jtreg Message-ID: <52149ACE.3030701@oracle.com> Hi List, I have some functional tests based on TestNG, the dir structure looks like: ========== a1/b1/Test1.java a2/b2/Test2.java a3/b3/Test3.java ========== For Test1.java and Test2.java, they are located in "a1.b1" or "a2.b2" package really. But for Test3.java, it is in default package. Here a3/b3 is only simple source directory. As you know, we can use TEST.properties to declare source root like below: ======= //it can be referenced to Test1 and Test2. Fail to get Test3. TestNG.dirs = . ======= or ======= //it can be referenced to Test3. Fail to get Test1 and Test2. TestNG.dirs = a3/b3 ======= My question is how I can reference to Test1, Test2 and Test3 at same time? It looks "TestNG.dirs = .;a3/b3" or "TestNG.dirs = . a3/b3" does not work. FYI, For some reason I want to keep all structure hierarchy. And I do not want to move Test.java into a3.b3 package. Could it be resolved through TEST.properties directly? Regards Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20130821/ec84267a/attachment.html