From aoqi at loongson.cn Mon Sep 3 08:19:51 2018 From: aoqi at loongson.cn (Ao Qi) Date: Mon, 3 Sep 2018 16:19:51 +0800 Subject: Fwd: [Patch] When the order of the parameters is different, the behavior of jtdiff is different. In-Reply-To: References: Message-ID: Dear Jonathan Gibbons, I understand it wrong. I thought -s is an option that takes a directory as an argument. I apologize for the wrong report and thanks for you detailed explanation. Because I just subscribed jtreg-dev at openjdk.java.net, I did not receive your email[1] and just saw it. Ao Qi [1] http://mail.openjdk.java.net/pipermail/jtreg-dev/2018-August/000692.html ---------- Forwarded message --------- From: Ao Qi Date: 2018?8?30??? ??8:36 Subject: [Patch] When the order of the parameters is different, the behavior of jtdiff is different. To: Hi all, I do not know if some one uses jtdiff. When I use this tool, I think I found a bug. When the order of the parameters is different, the behavior is different. $ jtdiff -s results/ -o tmp/ Error: Bad directory argument for "super" mode $ jtdiff -o tmp/ -s results/ Differences found. I found it is because when there are more then one args which start with "-", jtdiff do not set inFiles = false. I made a small patch to fix this. I did not test this patch very much. diff -r fdfb9ee98733 src/share/classes/com/sun/javatest/regtest/tool/OptionDecoder.java --- a/src/share/classes/com/sun/javatest/regtest/tool/OptionDecoder.java Fri Aug 03 16:03:18 2018 -0700 +++ b/src/share/classes/com/sun/javatest/regtest/tool/OptionDecoder.java Thu Aug 30 20:26:49 2018 +0800 @@ -81,6 +81,8 @@ throw new BadArgs(i18n, "opt.empty"); if (!arg.startsWith("-")) inFiles = true; + else + inFiles = false; if (inFiles) { fileOption.process(null, arg); } else In addition, $ jtdiff -h Compare Options --r | --reason Include the reason string in the comparison, as well as the type (i.e. Passed, Failed, etc.) --s | --super Perform a "super-diff" looking for result sets within a directory hierarchy. The hierarchy must be arranged as follows: PATH/PLATFORM/YEAR/DAY_OF_YEAR/TEST_RESULTS, where ... However, it should be "-s", not "--s". Thanks, Ao Qi From jonathan.gibbons at oracle.com Fri Sep 21 21:29:28 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 21 Sep 2018 14:29:28 -0700 Subject: [foreign] test_time timezone trouble (TZ) In-Reply-To: <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com> References: <548afe90ca8727551817bd4a3b215345@xs4all.nl> <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com> Message-ID: <5BA562B8.50807@oracle.com> Jorn, There is only limited amount of support for setting env variables in jtreg tests, because at least in the early releases of JDK, the use of environment variables was discouraged. Using `@run shell unsettz.sh` will not have the desired effect because it will only affect the shell that is created to run your shell script, and will not have a persistent environment on any other process. If you don't mind always setting a command-line option, you might try using `-eTZ=` on the jtreg command-line, which will unset TZ for all tests, although it would be more accurate to say that it will not set it for any tests. The only way to change the setting of TZ for any specific test will be to do one of the following: 1. Write the test as a shell script that unsets TZ and then runs any Java code, using various shell environment variables that will be available; these generally begin with "TEST". 2. Write the test as a Java program that execs a child process to run Java, with the exact set of environment variables you want to pass in. There are system properties that identify the test JDK, test class path and so on; these generally begin with "test.". These days, writing shell tests is generally discouraged, because it is notoriously difficult to get it right on all relevant platforms, and because these days, it is reasonably easy to use either the Java SE Process[Builder] API or test library API to invoke java. Hope that helps; if you have follow-up questions, please cc: me directly or use one of the jtreg-* aliases, since I am not on the panama-dev list. -- Jon On 09/21/2018 02:12 PM, Michel Trudeau wrote: > [adding jtreg mailing list to seek out answer about jtreg and TZ on Windows] > > On Sep 21, 2018, at 12:44 PM, Jorn Vernee wrote: > > Hello guys, > > I was running into a problem with the test_time test in StdLibTest. The generator for test values was apparently generating invalid values. After fixing that, all the test iterations were failing because the hours were off by one (the output of LocalDateTime.getHours() is being compared to the output of localtime().hour()). Good thing somebody else on the internet seems to have had the same problem [1]. TL;DR when using the MSVC version of localtime, and when running in cygwin, the function tries to interpret the TZ environment variable, but since that has a unix format (courtesy of cygwin), the interpretation fails and defaults to GMT. When TZ is not set, it defaults to the system default timezone, which is also what's being tested against. > > I can get the tests to pass by using `unset TZ` in the cygwin terminal before running them, but I'd have to do that every time I reboot it. I was trying to unset TZ automatically by using jtreq `@run shell unsettz.sh` where unsettz.sh is a file containing just the command `unset TZ`. It seems to be running successfully according to the test output: > > ACTION: shell -- Passed. Execution successful > REASON: User specified action: run shell unsettz.sh > TIME: 0.126 seconds > messages: > command: shell unsettz.sh > reason: User specified action: run shell unsettz.sh > elapsed time (seconds): 0.126 > STDOUT: > STDERR: > > But it doesn't seem to affect the tests itself, and they still fail (still off by 1 hour). > > I was wondering if there is a way to let jtreg control environment variables? Or maybe you can suggest a different solution? > > The jtreg guide [2] mentions that TZ will be propagated from Windows 'if set', but I need it to be not set, or automatically set to the system's default time zone (by default it's blank). > > (other than that, tests are looking good: `passed: 24; failed: 4; error: 1`. I just need to fix structs by value, which on Windows cheats and just passes a pointer. 2 failing tests are from jextract missing) > > Thanks, > Jorn > > [1] : https://stackoverflow.com/q/11655003 > [2] : http://openjdk.java.net/jtreg/tag-spec.html > From michel.trudeau at oracle.com Fri Sep 21 21:12:13 2018 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Fri, 21 Sep 2018 21:12:13 -0000 Subject: [foreign] test_time timezone trouble (TZ) In-Reply-To: <548afe90ca8727551817bd4a3b215345@xs4all.nl> References: <548afe90ca8727551817bd4a3b215345@xs4all.nl> Message-ID: <9FDB2BFC-2A7C-4485-9EAE-401669F86BF0@oracle.com> [adding jtreg mailing list to seek out answer about jtreg and TZ on Windows] On Sep 21, 2018, at 12:44 PM, Jorn Vernee wrote: Hello guys, I was running into a problem with the test_time test in StdLibTest. The generator for test values was apparently generating invalid values. After fixing that, all the test iterations were failing because the hours were off by one (the output of LocalDateTime.getHours() is being compared to the output of localtime().hour()). Good thing somebody else on the internet seems to have had the same problem [1]. TL;DR when using the MSVC version of localtime, and when running in cygwin, the function tries to interpret the TZ environment variable, but since that has a unix format (courtesy of cygwin), the interpretation fails and defaults to GMT. When TZ is not set, it defaults to the system default timezone, which is also what's being tested against. I can get the tests to pass by using `unset TZ` in the cygwin terminal before running them, but I'd have to do that every time I reboot it. I was trying to unset TZ automatically by using jtreq `@run shell unsettz.sh` where unsettz.sh is a file containing just the command `unset TZ`. It seems to be running successfully according to the test output: ACTION: shell -- Passed. Execution successful REASON: User specified action: run shell unsettz.sh TIME: 0.126 seconds messages: command: shell unsettz.sh reason: User specified action: run shell unsettz.sh elapsed time (seconds): 0.126 STDOUT: STDERR: But it doesn't seem to affect the tests itself, and they still fail (still off by 1 hour). I was wondering if there is a way to let jtreg control environment variables? Or maybe you can suggest a different solution? The jtreg guide [2] mentions that TZ will be propagated from Windows 'if set', but I need it to be not set, or automatically set to the system's default time zone (by default it's blank). (other than that, tests are looking good: `passed: 24; failed: 4; error: 1`. I just need to fix structs by value, which on Windows cheats and just passes a pointer. 2 failing tests are from jextract missing) Thanks, Jorn [1] : https://stackoverflow.com/q/11655003 [2] : http://openjdk.java.net/jtreg/tag-spec.html