http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/95 <pre>OK, I'll have to investigate this further and consult Other Authorities and get back to you. </pre> Jonathan Gibbons 2012-04-23T15:11:57 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/94 <pre>Hi Jon, Jonathon Gibbons wrote: &gt; Seems to me that you want /secure=java.lang.SecurityManager. I agree &gt; your use of -Djava.security.manager is intuitive and should be &gt; considered as an RFE. Unfortunately using /secure doesn't work: ACTION: build -- Not run. Test running... REASON: Named class compiled on demand TIME: java.lang.SecurityManager seconds messages: command: build .secure=java.lang.SecurityManager reason: Named class compiled on demand TEST RESULT: Error. Can't find source file: /secure=java/lang/SecurityManager.java in directory-list: /java/embedded/users/dh198349/dev-work/jdk-7103570/test/java/util/concurrent/atomic David ----- </pre> David Holmes 2012-04-22T22:47:13 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/93 <pre>jtreg has special handling and support for security managers, so that it can ensure it has permissions to do its job as well as let you do yours. I've not played much in this area, but reading the tag-spec [1] I see the following sections. Seems to me that you want /secure=java.lang.SecurityManager. I agree your use of -Djava.security.manager is intuitive and should be considered as an RFE. </pre> Jonathan Gibbons 2012-04-20T22:18:15 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/92 <pre>Hi Jon, I have a new test that requires that a security manager be installed, so I have: &lt; at &gt;run main/othervm -Djava.security.manager but this causes jtreg itself to encounter a security exception: Exception in thread "main" java.security.AccessControlException: access denied ("java.io.FilePermission" "/scratch/dh198349/dev-work/b11/linux-i586-dh/testoutput/jdk_util/JTwork/classes/java/util/concurrent/atomic/AtomicUpdaters.jta" "read") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:555) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at java.io.FileInputStream.&lt;init&gt;(FileInputStream.java:121) at java.io.FileInputStream.&lt;init&gt;(FileInputStream.java:87) at java.io.FileReader.&lt;init&gt;(FileReader.java:58) at com.sun.javatest.regtest.MainWrapp</pre> David Holmes 2012-04-19T04:40:45 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/91 <pre>Currently, you can only file issues inside Oracle on Bugtraq under jct_tools/jct_tools/regtest. For non-Oracle folk, report issues here and I'll make sure issues get filed for them. As a workaround there is a command line option to pass env variables into a test. See "jtreg -help -e" -e:name[=value][,name[=value]...] Specify additional environment variables to be passed to each test. If a value is not given for a name, the current value of the environment variable will be used. Standard environment variables, like DISPLAY, LANG, windir, SystemRoot, etc, will automatically be given to each test, if they are set in the current environment. </pre> Jonathan Gibbons 2011-11-18T14:25:03 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/90 <pre> Where it is possible to file a jtreg issue? Thanks, Alexandr. On 10/21/2011 1:49 PM, Alexander Scherbatiy wrote: </pre> Alexander Scherbatiy 2011-11-18T08:08:01 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/89 <pre> Which version of jtreg are you using? I thought all paths got converted to absolute paths long ago. </pre> Jonathan Gibbons 2011-11-16T22:55:51 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/88 <pre>I don't understand your reasoning/math in your 2nd para below. Did you mean 5 + (2*1) ?? Otherwise, according to my high school math, 2*(5+1) == (2*5) + (2*1). Timeouts are not meant to be reached in normal use. They are intended to catch runaway tests, doing stuff like "while(true);". Therefore, I don't think we should be micromanaging time too much. If the test is written to take 6 seconds on a typical machine, consisting of 5 seconds activity and 1 second cleanup, then on a slower machine it should be acceptable to use timefactor=2 and give it 12 seconds. Internally, the test should not need to know it is running on a slower machine; it should proceed to do the same activity as before, and if it now takes 5 seconds activity + (2*1) cleanup, well, 5 + 2*1 &lt; 2*(5 + 1) and the test will continue to pass. </pre> Jonathan Gibbons 2011-11-16T22:54:08 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/87 <pre>I recently discovered that using relative paths for the -jdk option fails for some of the shell script tests because they expect the jdk path to be an absolute path. (yet one more reason to hate shell tests). About 100 tests fail in jdk/test/test because of the absolute path requirement to their driver shell scripts. Is there any chance that jtreg could convert the path provided to -jdk to an absolute path? being able to use a relative path on the command line is certainly more convenient. Thanks, Mike </pre> Mike Duigou 2011-11-16T22:45:05 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/86 <pre>Hi Jon, I don't think it is as simple as designating a length of time a test is allowed to run. In the scenario, I mentioned below a test needed 5 seconds to perform it's main task and 1 second to clean up. Internally both operations were manged with separate timeouts. The jtreg harness allows for timefactor=2 to allow for 2*(5+1) or 12 seconds to complete, but the test as written really needs (2*5) + (2*1) seconds to run correctly. e.g. it has to allow for 2 seconds in the cleanup on the slower machine. If we can provide the (6 seconds * 2 timefactor) to the test it could divide up the time between subtasks, but that may be a fairly complicated computation over a large number of tests currently using hard coded timeouts. Gary ======= With respect, my sense is that this is somewhat misdirected micromanagement. It's not the time factor that the test should know, but the actual allotted time. Given a certain period of time, a test could breakdown the allotted time into intervals for each step </pre> Gary Adams 2011-11-16T22:08:08 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/85 <pre>Gary, With respect, my sense is that this is somewhat misdirected micromanagement. It's not the time factor that the test should know, but the actual allotted time. Given a certain period of time, a test could breakdown the allotted time into intervals for each step of its processing. Would that work for what you have in mind? </pre> Jonathan Gibbons 2011-11-16T17:21:01 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/84 <pre>This may not be the best place to discuss JPRT infrastructure, but I'm curious how the automated testing knows which systems have which prerequisites available. e.g. which system runs linux/x86 versus linux/arm Obviously, binaries need to be matched to the systems that can run them. Would it be possible for that "available systems" mapping to include the available memory and cpu speeds. e.g. Information from "cat /proc/{mem,cpu}info" or from "cpufreq-info" command </pre> Gary Adams 2011-11-16T16:51:33 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/83 <pre> I'm not concerned how the timefactor is set. It could be from makefiles or could be from developer running jtreg from the command line. What I'm talking about is the actual test code being informed that the timefactor is being applied. e.g. communicated from the test harness to the test case A typical test using timeouts internally has some expectation how long particular tasks will take. It might use 5 seconds for threads to be set up and then 1 second delay while each thread is shut down. An overall timefactor setting will still catch the runaway test, but in some cases the test will terminate prematurely because individual steps were not alloted sufficient time. On 11/16/11 11:21 AM, Kelly O'Hair wrote: </pre> Gary Adams 2011-11-16T16:36:42 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/82 <pre>The jdk/test/Makefile that runs jtreg for JPRT (and the TL Nightly now?), adds a -timefactor:2 option I think, you could have the test/Makefile detect a slower system and adjust the timefactor on the command line there. Or is that what you are suggesting? I know it's a bit crude to use Makefiles as an interface for testing, but there is a big advantage to JPRT, Nightly testing, and developers being able to run the tests the exact same way. -kto On Nov 16, 2011, at 5:08 AM, Gary Adams wrote: </pre> Kelly O'Hair 2011-11-16T16:21:26 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/81 <pre>Gary, If command line values were to be made available, it would probably be best to use system properties, but it feels like this is wrong, as a general solution. I could see making specific values available, such as the timeout factor, but even then I think it would be better to a more specific proposal of how this would be used by tests running on slower machines. </pre> Jonathan Gibbons 2011-11-16T14:53:53 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/80 <pre>I'm investigating the current jdk tests with timeouts to see if we can make them more reliable for slower machines. As a a first step, I want to see if the jtreg command line arguments can be made visible to the individual test. Second I want to explore the information about the target machine that can help adjust time limits from the time sensitive tests. -------- Original Message -------- Subject: Re: Passing time factor to tests run under jtreg Date: Tue, 15 Nov 2011 22:45:03 +0000 From: Alan Bateman &lt;Alan.Bateman-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; To: gary Adams &lt;Gary.Adams-veTT2BtV2gBXrIkS9f7CXA&lt; at &gt;public.gmane.org&gt; CC: core-libs-dev-0nJqbsLSQw0FDOXUYO6UHQ&lt; at &gt;public.gmane.org Gary - this might be something to bring up on the jtreg-use list. Ideally the tests wouldn't have any hardcoded timeouts but sometimes there isn't any other choice. -Alan On 15/11/2011 20:14, Gary Adams wrote: </pre> Gary Adams 2011-11-16T13:08:29 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/79 <pre>Hi, The UIManager.getSystemLookAndFeelClassName() runnning in the test method by jtreg returns different L&amp;Fs than it is run under JDK on the Solaris when the GNOME_DESKTOP_SESSION_ID is set. It is because the jtreg does not pass the GNOME_DESKTOP_SESSION_ID system variable to the tested JDK and so the JDK does not set the sun.desktop system variable. To check this set the GNOME_DESKTOP_SESSION_ID system variable on the Solaris and run the following code under java 1.7 and jtreg: --- TestSunDesktopSystemVariable.java --- /* * &lt; at &gt;test * &lt; at &gt;summary Check that sun.desktop variable is set in JDK if the GNOME_DESKTOP_SESSION_ID system variable is set on Solaris OS * &lt; at &gt;run main TestSunDesktopSystemVariable */ public class TestSunDesktopSystemVariable { public static void main(String[] args) { String sunDesktop = System.getProperty("sun.desktop"); System.out.println("desktop = " + sunDesktop); if(sunDesktop == null){ throw new RuntimeException("The sun.</pre> Alexander Scherbatiy 2011-10-21T09:49:37 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/78 <pre> Mike, In cases like this, I think it would be expected that you run the test outside the jtreg framework. All API tests written in Java should have a main program. Is this a reasonable way for you to proceed? </pre> Jonathan Gibbons 2011-07-29T21:29:30 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/77 <pre>I'm working on a bug that involves a lot of reflection and proxies and trying to debug it using the jtreg unit test and attaching to the process with netbeans debugger. I initially ran into problems when jtreg timed out the test after 120 seconds. I then tried increasing the timeout value but my requests for "10000000" were rejected. I'm currently using a timeout factor of 100 but it would be nice to be able to say "-timeout:never". Is there a way to disable timeouts entirely? Mike </pre> Mike Duigou 2011-07-29T21:05:16 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/76 <pre> According to http://openjdk.java.net/jtreg/faq.html#question4.1, by design, PATH is not propagated into the test's JVM; instead, * Linux and Solaris: o PATH is set to /bin:/usr/bin * Windows: o PATH is set to the MKS or Cygwin toolkit binary directory What is the rationale behind of restricting the shell tests to use commands from /bin:/usr/bin? We have tests that depend on gawk which is not installed in /bin:/usr/bin on Solaris 10 by default (instead /opt/sfw/bin) unless I add a symlink or copy them. These tests fail if I use jtreg to run them. Thanks Mandy </pre> Mandy Chung 2011-03-04T23:34:12 http://permalink.gmane.org/gmane.comp.java.openjdk.jtreg.user/75 <pre>The copy of the jtreg tag specification posted at &lt;http://openjdk.java.net/jtreg/tag-spec.txt&gt; is an older version (1.25 06/10/24) than the version included in the online help (1.26 09/10/10) for jtreg 4.1 fcs b02. Also, a less ambiguous date format such as 2011-02-13 would be nice. :-) Cheers, Mike </pre> Mike Duigou 2011-02-13T18:28:55 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.openjdk.jtreg.user