headers
Mike Duigou | 16 Nov 23:45
Picon
Favicon

-jdk and releative paths

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
Permalink | Reply | 1 comment |
headers
Alexander Scherbatiy | 21 Oct 11:49
Picon
Favicon

jtreg does not pass the GNOME_DESKTOP_SESSION_ID system variable to the tested JDK

Hi,

The  UIManager.getSystemLookAndFeelClassName() runnning in the test 
method by jtreg returns different L&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 ---
/*
  * @test
  * @summary Check that sun.desktop variable is set in JDK if the 
GNOME_DESKTOP_SESSION_ID system variable is set on Solaris OS
  * @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.desktop system variable 
is not set");
         }
     }
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike Duigou | 29 Jul 23:05
Picon
Favicon

Infinite Timeout?

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
Permalink | Reply | 1 comment |
headers
Mandy Chung | 5 Mar 00:34
Picon
Favicon

PATH not propagated to the test's JVM

  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
Permalink | Reply | 0 comments |
headers
Mike Duigou | 13 Feb 19:28
Picon
Favicon

Tag spec update needed on openjdk.java.net

The copy of the jtreg tag specification posted at <http://openjdk.java.net/jtreg/tag-spec.txt> 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
Permalink | Reply | 0 comments |
headers
Mike Duigou | 24 Jan 22:01
Picon
Favicon

jtreg -vmoption(s) vs. -javaoption(s)

I'm trying to understand what differences in usage there are for the -vmoption and -javaoption flags. From
my reading of RegressionParameters.getTestVMJavaOptions() it would seem than in practice the two
options are interchangeable. Is there some other distinction I am missing? The command line help
includes a see also for each to the other but doesn't explain any difference.

Mike
Permalink | Reply | 1 comment |
headers
Pavel Tisnovsky | 18 Nov 12:26
Picon
Favicon

Tag option "process" is missing in JTreg documentation

Hi all,

I realized that OpenJDK regression test
langtools/tools/javac/processing/6499119/ClassProcessor.java uses the
tag "@compile" followed by tag option "process".

But this tag+option pair is not mentioned (or I'm unable to find it ;-)
in tag specification:
http://openjdk.java.net/jtreg/tag-spec.txt

I also tried to find in newest JTreg harness sources where this option
is processed and it in fact exists (CompileAction.java).

So I think that tag specification on openjdk.java.net should be updated.
If I'm right can anybody please do it?

Thank you in advance,
Pavel Tisnovsky
Permalink | Reply | 1 comment |
headers
Omair Majid | 11 Feb 19:38
Picon
Favicon

jtreg throws StackOverflowError when writing xml report

Hi all,

I am trying to generate xml reports from jtreg. The problem is that 
jtreg throws a StackOverflowError when writing the output xml file when 
running the jdk tests. The xml report works fine for the 16 compiler 
tests and 1351 langtools tests.

I am using Icedtea6 to run the tests. These are the commands it executes:

$ mkdir -p test/jdk/JTwork test/jdk/JTreport
$ /notnfs/omajid/icedtea6/bootstrap/jdk1.6.0/bin/java \
         -Djavatest.report.kinds="xml text html" \
         -jar test/jtreg.jar -v1 -a -ignore:quiet \
         -w:test/jdk/JTwork -r:test/jdk/JTreport \
         -s -jdk:`pwd`/openjdk/control/build/linux-i586/j2sdk-image \
         `pwd`/openjdk/jdk/test \
         | tee test/check-jdk.log

The error appears after the jtreg run completes:

[ lots of output ]
Passed: vm/verifier/VerifyProtectedConstructor.java
Passed: vm/verifier/VerifyStackForExceptionHandlers.java
Test results: passed: 3,306; failed: 73; error: 5
Exception in thread "main" java.lang.StackOverflowError
     at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:76)
     at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:411)
     at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:466)
     at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561)
     at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:258)
(Continue reading)

Permalink | Reply | 11 comments |
headers
Martin Buchholz | 1 Feb 22:36
Picon
Favicon

What's up with jdk/test/TestEnv.java?

I've been trying to get the jtreg tests
currently failing with UnknownHostException
to start passing instead.

I looked at jdk/test/TestEnv.java
which looks perfectly designed for our needs.

But it's not in openjdk7...!?!?
(normally I would expect to see things the other way around)
In openjdk7 I just see the hostnames hardcoded into
jdk/test/java/nio/channels/TestUtil.java

Do y'all plan to forward-port jdk/test/TestEnv.java to openjdk7?

Thanks,

Martin
Permalink | Reply | 2 comments |
headers
Mahmood Ali | 16 Dec 02:00
Picon
Favicon

RFE: compile/fail tag to recognize compiler failures

Greetings,

I would like to request changing compile/fail tag semantics a bit.

Currently if the compile fails to compile the provided class, the test  
passes regardless of the reason of the failure.  jtreg does not  
distinguish between failures due to compiler reported errors or  
unexpected exceptions in the compiler.

I request that jtreg to recognize these unexpected errors and treat  
them differently from expected errors and not ignore them silently.

Regards,
Mahmood
Permalink | Reply | 1 comment |
headers
Mark Wielaard | 23 Nov 18:17
Favicon
Gravatar

Allowing partial jtreg samejvm safe runs

Hi,

Jonathan Gibbons has been extending jtreg so that tests can be run in
the same vm. He also made it so that most langtools tests are run that
way. That brings an enormous speed up. Since running all jdk tests takes
ages it would be great if we could use this same speedup there.

Problem is that -samevm only works if all tests have been adapted to
behave well (or marked as needing /othervm). So my idea was to add a
"whitelist mechanism" so you can indicate which (sub)dirs are ready to
be run with samevm.

Luckily jtreg has mostly been setup for this already. All Actions ask
their Script whether or not they should be running in an othervm. So we
hook into that to check the scripts location against a whitelist.

I choose the TEST.ROOT file as the location of the whitelist. Since that
is also the root of the test suite. I made the code so that the
whitelist is only used when running the full test suite from the root.
That way you can still experiment with -samevm or -othervm when running
subtrees of tests.

Also CCed jdk-regtest@... since that address is mentioned in the
TEST.ROOT file with an request to contact them if you change anything in
that file.

Below is the implementation as I checked into icedtea6 (patch also
attached).

2008-11-23  Mark Wielaard  <mark@...>
(Continue reading)

Permalink | Reply | 3 comments |

Gmane