JDK-8215326 : Test java/util/concurrent/ConcurrentHashMap/ToArray.java hangs after j.u.c updates
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-12-13
  • Updated: 2020-04-09
  • Resolved: 2018-12-13
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 12 JDK 13
12 b24Fixed 13Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Since the j.u.c updates in: 

JDK-8214427  probable bug in logic of ConcurrentHashMap.addCount()
JDK-8214559  Use {@systemProperty} for definitions of system properties

were pushed we have started to see this test timeout on multiple platforms. Running the test locally it seems to hang.

I bisected to this commit in jsr166 CVS: revision 1.351 date: 2018/12/05 11:03:24; author: dl; state: Exp; lines: +61 -52 Reduce unnecessary signals We'll just roll back.

OK, I can reproduce a hang about 1% of the time if I run the test repeatedly.

I'm about to head out for a few days so can't isolate which of the two changesets cause the problem. It fails in our testing on Windows x64 and locally for me on linux x64 fastdebug. But JDK-8214559 is supposed to be a doc comment change only so it definitely needs backing out and reapplying as two separate bugs. Thanks.

This integration did contain changes to ConcurrentHashMap, which may need to be backed out. Naturally, we jsr166 folks don't see any failures. Can someone who can reproduce the failure determine which changeset is at fault? Sorry for our somewhat sloppy integrations from CVS - we only isolate changes at file level granularity.

It looks like JDK-8214559 may have pushed a bad changeset as it contains code changes unrelated to that bug report!

Sigh. I should have stressed-tested toArray test again, because it would have reminded me that a re-inserted (and now re-removed) signal filter ("s != b") does not apply during shutdown etc, and always-applicable check is too expensive to use. I reverted only that change.