<br>Hi Jonathan,<div><br></div><div>thanks for you comments. But there's still one thing I don't understand: what's the exact reason that tests in the agentvm mode are running under a special security manager while test running in othervm mode aren't restricted in this way. Is this really necessary?</div>
<div><br></div><div>Regards,</div><div>Volker </div><div><br>On Tuesday, December 10, 2013, Jonathan Gibbons wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Volker,<br>
<br>
>From the history books, initially there was only "samevm" and "othervm" mode and "othervm" mode was the default.<br>
<br>
"samevm" mode was problematic in the face of bad tests (especially bad tests on Windows) and only the langtools test suite evolved to the point where we recommended the use of "samevm" mode.<br>
<br>
As a result, "agentvm" mode was added, which is <marketing-slogan>like samevm, but better</marketing-slogan>. It has worked well for most tests, but as you have noticed, does not work well if a test tries to exit the JVM. Those tests need some amount of TLC if they are to leverage "agentvm" mode.<br>
<br>
You can use othervm.dirs in TEST.ROOT, but that was added as a pragmatic, stop gap measure, to faciitate running most of the tests in the faster "agentvm" mode, while allowing some older parts of the test suite to continue running in the slower "othervm" world.<br>
<br>
The core-libs team have led an effort to clean up the core-libs tests and to provide the test/Makefile as a standard way of running the tests. It seems like it is time to embark on a similar effort for the client tests.<br>
<br>
-- Jon<br>
<br>
On 12/10/2013 07:37 AM, Volker Simonis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
when running the<br>
com/sun/java/swing/plaf/<u></u>windows/8016551/bug8016551.<u></u>java regression<br>
test with the newest version of jtreg (build from source) in agentvm<br>
mode I get the following error:<br>
<br>
----------System.err:(33/2049)<u></u>----------<br>
java.lang.reflect.<u></u>InvocationTargetException<br>
at java.awt.EventQueue.<u></u>invokeAndWait(EventQueue.java:<u></u>1300)<br>
at java.awt.EventQueue.<u></u>invokeAndWait(EventQueue.java:<u></u>1275)<br>
at javax.swing.SwingUtilities.<u></u>invokeAndWait(SwingUtilities.<u></u>java:1350)<br>
at bug8016551.main(bug8016551.<u></u>java:46)<br>
at sun.reflect.<u></u>NativeMethodAccessorImpl.<u></u>invoke0(Native Method)<br>
at sun.reflect.<u></u>NativeMethodAccessorImpl.<u></u>invoke(<u></u>NativeMethodAccessorImpl.java:<u></u>62)<br>
at sun.reflect.<u></u>DelegatingMethodAccessorImpl.<u></u>invoke(<u></u>DelegatingMethodAccessorImpl.<u></u>java:43)<br>
at java.lang.reflect.Method.<u></u>invoke(Method.java:483)<br>
at com.sun.javatest.regtest.<u></u>MainAction$SameVMRunnable.run(<u></u>MainAction.java:754)<br>
at java.lang.Thread.run(Thread.<u></u>java:744)<br>
Caused by: java.lang.SecurityException: System.exit() forbidden by JT Harness<br>
at com.sun.javatest.<u></u>JavaTestSecurityManager.<u></u>checkExit(<u></u>JavaTestSecurityManager.java:<u></u>117)<br>
at javax.swing.JFrame.<u></u>setDefaultCloseOperation(<u></u>JFrame.java:395)<br>
at bug8016551$1.run(bug8016551.<u></u>java:57)<br>
at java.awt.event.<u></u>InvocationEvent.dispatch(<u></u>InvocationEvent.java:301)<br>
at java.awt.EventQueue.<u></u>dispatchEventImpl(EventQueue.<u></u>java:744)<br>
at java.awt.EventQueue.access$<u></u>400(EventQueue.java:97)<br>
at java.awt.EventQueue$3.run(<u></u>EventQueue.java:697)<br>
at java.awt.EventQueue$3.run(<u></u>EventQueue.java:691)<br>
at java.security.<u></u>AccessController.doPrivileged(<u></u>Native Method)<br>
at java.security.<u></u>ProtectionDomain$1.<u></u>doIntersectionPrivilege(<u></u>ProtectionDomain.java:75)<br>
at java.awt.EventQueue.<u></u>dispatchEvent(EventQueue.java:<u></u>714)<br>
at java.awt.EventDispatchThread.<u></u>pumpOneEventForFilters(<u></u>EventDispatchThread.java:201)<br>
at java.awt.EventDispatchThread.<u></u>pumpEventsForFilter(<u></u>EventDispatchThread.java:116)<br>
at java.awt.EventDispatchThread.<u></u>pumpEventsForHierarchy(<u></u>EventDispatchThread.java:105)<br>
at java.awt.EventDispatchThread.<u></u>pumpEvents(<u></u>EventDispatchThread.java:101)<br>
at java.awt.EventDispatchThread.<u></u>pumpEvents(<u></u>EventDispatchThread.java:93)<br>
at java.awt.EventDispatchThread.<u></u>run(EventDispatchThread.java:<u></u>82)<br>
<br>
If the test is run in othervm mode it succeeds.<br>
<br>
I looked at this problem a litter loser and found out the following:<br>
<br>
- there are 99 test which use JFrame.<u></u>setDefaultCloseOperation(EXIT_<u></u>ON_CLOSE)<br>
- they are in java/awt (15), javax/swing (79), sun/java2d (3),<br>
javax/imageio/plugins/gif/<u></u>GifTransparencyTest.java<br>
(setDefaultCloseOperation present but never called) and<br>
com/sun/java/swing/plaf/<u></u>windows/8016551/bug8016551.<u></u>java<br>
- all test in java/awt and sun/java2d are always executed in othervm<br>
mode anyway (because of 'othervm.dirs=java/awt ..' in TEST.ROOT)<br>
<br>
Now I'm not sure if this security-exception is right at this place -<br>
i.e. if jtreg/jtharness work as expected here.<br>
<br>
If yes and if there's no option/workaround to switch this behaviour<br>
off, we should either add 'javax/swing' as well to the 'othervm.dirs'<br>
list in TEST.ROOT and explicitly flag the remain test to require<br>
othervm mode by adding the corresponding '@run main/othervm' tag to<br>
the java source file.<br>
<br>
If adding 'javax/swing' to 'othervm.dirs' is considered to general, we<br>
would have to explicitly flag each single test with '@run<br>
main/othervm'.<br>
<br>
What do you think?<br>
<br>
Volker<br>
<br>
PS: there are 208 test which call System.exit() directly. I haven't<br>
analysed them until now, but the same reasoning applies for them as<br>
well.<br>
</blockquote>
<br>
</blockquote></div>