JDK-8176551 : testCommonPoolThreadContextClassLoader fails with "Should throw SecurityException"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-03-13
  • Updated: 2017-03-25
  • Resolved: 2017-03-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 9
10Fixed 9 b162Fixed
Related Reports
Relates :  
Relates :  
Description
JDK-8172726 introduced java/util/concurrent/tck/ForkJoinPool9Test.java

This test, run by java/util/concurrent/tck/JSR166TestCase.java
 * @run junit/othervm/timeout=1000/policy=tck.policy
 *      -Djsr166.testImplementationDetails=true
 *      JSR166TestCase

fails at some (2-core machine?) platform/machine, reproducible (9/156 and later)

#section:junit
----------messages:(5/445)----------
command: junit -Djsr166.testImplementationDetails=true JSR166TestCase
reason: User specified action: run junit/othervm/timeout=1000/policy=tck.policy -Djsr166.testImplementationDetails=true JSR166TestCase 
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules java.base,java.management --add-opens java.base/java.util.concurrent=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED
elapsed time (seconds): 19.512
----------configuration:(5/175)----------
Boot Layer
  add modules: java.base java.management      
  add opens:   java.base/java.lang            ALL-UNNAMED
               java.base/java.util.concurrent ALL-UNNAMED

----------System.out:(0/0)----------
----------System.err:(28/1968)----------
JavaTest Message: JUnit Failure: testCommonPoolThreadContextClassLoader(ForkJoinPool9Test): junit.framework.AssertionFailedError: Should throw java.lang.SecurityException
java.util.concurrent.CompletionException: junit.framework.AssertionFailedError: Should throw java.lang.SecurityException
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
	at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: junit.framework.AssertionFailedError: Should throw java.lang.SecurityException
	at junit.framework.Assert.fail(Assert.java:50)
	at JSR166TestCase.shouldThrow(JSR166TestCase.java:1163)
	at JSR166TestCase.assertThrows(JSR166TestCase.java:1964)
	at ForkJoinPool9Test.lambda$testCommonPoolThreadContextClassLoader$2(ForkJoinPool9Test.java:68)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
	... 1 more

java.lang.Exception: JUnit test failure
	at com.sun.javatest.regtest.agent.JUnitRunner.main(JUnitRunner.java:87)
	at com.sun.javatest.regtest.agent.JUnitRunner.main(JUnitRunner.java:43)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:543)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
	at java.base/java.lang.Thread.run(Thread.java:844)
Comments
David may have had trouble reproducing it because work stealing is actually racy, although for me it repro'ed consistently with 2 threads (taskset 0x3) but never with more than 2.
14-03-2017

I suspected the problem was the test logic was not being run on a pool thread, but using a stripped down version and taskset I was unable to reproduce it. I suspect I needed more specific SM and policy details.
13-03-2017

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-integration/testCommonPoolThreadContextClassLoader/ This test must cause code to run in a real common pool thread, and has to deal both with the common pool having no threads at all, and with the main thread unhelpfully "helping" on task join.
13-03-2017

I can reproduce the failure at two cores machine. I tried 2-cores linux (oel 7) and 2-cores solaris-x64 (solaris 11), test FAIL. But for same OS, I also tried 32-cores machine, test PASS. The test has two @test tag, to reproduce, I have to delete the first @test section, so as force the second @test to run. (when run all tests, this results java/util/concurrent/tck/JSR166TestCase.java#id1 )
13-03-2017

All the @test are executed with arg jtreg java/util/concurrent/tck/ instead of jtreg java/util/concurrent/tck/JSR166TestCase.java On Linux, we can use the taskset command to restrict the number of CPUs. I can rreproduce the problem with taskset 0x3 jtreg ... java/util/concurrent/tck/ while taskset 0x7 jtreg ... java/util/concurrent/tck/ passes.
13-03-2017