JDK-8256640 : assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-11-19
  • Updated: 2020-11-26
  • Resolved: 2020-11-19
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 16
16 b26Fixed
Related Reports
Duplicate :  
JDK-8256674 - assert failed: "old methods should not be in vtable"
Relates :  
JDK-8256365 - Clean up vtable initialization code
Description
# Symptom

```
IsModifiableClassAgent started
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/klassVtable.cpp:564
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/root/df/jdk/src/hotspot/share/oops/klassVtable.cpp:564), pid=10502, tid=10505
#  assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable
#
# JRE version: OpenJDK Runtime Environment TencentKonaJDK (16.0+4) (fastdebug build 16-internal+4-adhoc.root.jdk)
# Java VM: OpenJDK 64-Bit Server VM TencentKonaJDK (fastdebug 16-internal+4-adhoc.root.jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x10fdc84]  klassVtable::put_method_at(Method*, int)+0x2e4
```

# Reproduce

jtreg run: java/lang/instrument/IsModifiableClassAgent.java
Comments
Changeset: fae68ff0 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2020-11-19 22:39:07 +0000 URL: https://github.com/openjdk/jdk/commit/fae68ff0
19-11-2020
I took the bug because I have a fix for this and for the bug that I found through inspection which motivated the new assert. This test is run in tier5 and 6, which is why I didn't get the failure on the original change.
19-11-2020
Ok, so that's not where I expected it to be. Edit: no maybe that makes sense. If we're redefining classes that are owners of the default methods in the safepoint while populating the table, the method in the methodHandle may be old. The default methods array is updated, but not the methodHandles on the stack (on purpose). So we have to refetch the method in the default_methods array.
19-11-2020
hs_err had been added. Thanks.
19-11-2020
I had a patch in the RFE above [v1] that I took out because I didn't think it was something that could be reproduced. Can you add the hs_err_pid* file to this so I can see if it needs the change I thought it needed?
19-11-2020