System.exit() forbidden by JT Harness in agentvm mode

Jonathan Gibbons jonathan.gibbons at
Tue Dec 10 08:47:52 PST 2013


 From the history books, initially there was only "samevm" and "othervm" 
mode and "othervm" mode was the default.

"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.

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.

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.

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.

-- Jon

On 12/10/2013 07:37 AM, Volker Simonis wrote:
> Hi,
> when running the
> com/sun/java/swing/plaf/windows/8016551/ regression
> test with the newest version of jtreg (build from source) in agentvm
> mode I get the following error:
> ----------System.err:(33/2049)----------
> java.lang.reflect.InvocationTargetException
>          at java.awt.EventQueue.invokeAndWait(
>          at java.awt.EventQueue.invokeAndWait(
>          at javax.swing.SwingUtilities.invokeAndWait(
>          at bug8016551.main(
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at sun.reflect.NativeMethodAccessorImpl.invoke(
>          at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>          at java.lang.reflect.Method.invoke(
>          at com.sun.javatest.regtest.MainAction$
>          at
> Caused by: java.lang.SecurityException: System.exit() forbidden by JT Harness
>          at com.sun.javatest.JavaTestSecurityManager.checkExit(
>          at javax.swing.JFrame.setDefaultCloseOperation(
>          at bug8016551$
>          at java.awt.event.InvocationEvent.dispatch(
>          at java.awt.EventQueue.dispatchEventImpl(
>          at java.awt.EventQueue.access$400(
>          at java.awt.EventQueue$
>          at java.awt.EventQueue$
>          at Method)
>          at$1.doIntersectionPrivilege(
>          at java.awt.EventQueue.dispatchEvent(
>          at java.awt.EventDispatchThread.pumpOneEventForFilters(
>          at java.awt.EventDispatchThread.pumpEventsForFilter(
>          at java.awt.EventDispatchThread.pumpEventsForHierarchy(
>          at java.awt.EventDispatchThread.pumpEvents(
>          at java.awt.EventDispatchThread.pumpEvents(
>          at
> If the test is run in othervm mode it succeeds.
> I looked at this problem a litter loser and found out the following:
> - there are 99 test which use JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE)
> - they are in java/awt (15), javax/swing (79), sun/java2d (3),
> javax/imageio/plugins/gif/
> (setDefaultCloseOperation present but never called) and
> com/sun/java/swing/plaf/windows/8016551/
> - all test in java/awt and sun/java2d are always executed in othervm
> mode anyway (because of 'othervm.dirs=java/awt ..' in TEST.ROOT)
> Now I'm not sure if this security-exception is right at this place -
> i.e. if jtreg/jtharness work as expected here.
> If yes and if there's no option/workaround to switch this behaviour
> off, we should either add 'javax/swing' as well to the 'othervm.dirs'
> list in TEST.ROOT and explicitly flag the remain test to require
> othervm mode by adding the corresponding '@run main/othervm' tag to
> the java source file.
> If adding 'javax/swing' to 'othervm.dirs' is considered to general, we
> would have to explicitly flag each single test with '@run
> main/othervm'.
> What do you think?
> Volker
> PS: there are 208 test which call System.exit() directly. I haven't
> analysed them until now, but the same reasoning applies for them as
> well.

More information about the quality-discuss mailing list