JDK-8030662 : "assert(counter_changed) failed: failed dependencies, but counter didn't change" still fails
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-12-17
  • Updated: 2016-11-23
  • Resolved: 2014-01-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 8 JDK 9
8u20Fixed 9 b03Fixed
Related Reports
Relates :  
JDK-8170130 - Compilation fails with "assert(counter_changed) failed: failed dependencies, but counter didn't change"
Description
The assert "assert(counter_changed) failed: failed dependencies, but counter didn't change" still fails after committing  https://bugs.openjdk.java.net/browse/JDK-8029383
Comments
I=H (crash) L=L (corner case; you need to use JVMTI, redefine a class and hit a race condition) W=H (no workaround) ILW=HLH=P2
11-03-2014
RULE nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 Crash Internal Error ...ciEnv.cpp...assert(counter_changed) failed: failed dependencies, but counter didn't change RULE nsk/jvmti/scenarios/hotswap/HS104/hs104t002 Crash Internal Error ...ciEnv.cpp...assert(counter_changed) failed: failed dependencies, but counter didn'unsigned short change RULE nsk/jvmti/scenarios/hotswap/HS104/hs104t002 Crash assert(counter_changed) failed: failed dependencies, but counter didn't change
16-01-2014
regarding lack of test case: requires use of jvmti concurrently with JIT compilation so a reliable test case is hard to write.
14-01-2014
Release team: Not a showstopper. Defering to 8u20
09-01-2014
The end user has to use JVMTI, redefine classes with JVMTI and there must be a race between a compilation that depends on the class being redefined and the class redefinition. It's a corner case. Diff: http://cr.openjdk.java.net/~roland/8030662/webrev.00/
07-01-2014
Release team: We'd like to understand what the likelihood is of this happening for an end-user (not from the perspective of running one of our tests). Is this a corner case or a regular case? Also, do you have the diff/webrev for this fix that you can attach?
07-01-2014
ILW=HMH=>P1 Impact: Crash hence high Likelihood: Easily reproduceable Workaround: No workaround Justification: The original bug (JDK-8029383) was not fixed fully and still fails in some cases. The original issue is still there Evaluation: When JDK-8029383 was fixed, I removed a call to SystemDictionary::notice_modification() from VM_RedefineClasses in jvmti because that code calls SystemDictionary::parse_stream() and I had added a new call to SystemDictionary::notice_modification() there. What I overlooked is that the jvmti code passes a null handle for host_klass when it calls parse_stream and so the new call to notice_modification() is not performed in this context. Risk Assessment: Risk is low. The code was not redundant. So the fix only put what was redundant back where it was. Testing: Failing test from nightly
06-01-2014
When I fixed 8029383, I removed a call to SystemDictionary::notice_modification() from VM_RedefineClasses in jvmti because that code calls SystemDictionary::parse_stream() and I had added a new call to SystemDictionary::notice_modification() there. What I overlooked is that the jvmti code passes a null handle for host_klass when it calls parse_stream and so the new call to notice_modification() is not performed in this context.
18-12-2013