JDK-8222004 : VM crashes with: assert(!value || !is_old() || is_obsolete() || is_running_emcp()) failed: emcp methods cannot run after emcp bit is cleared
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 11,13
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2019-04-04
  • Updated: 2021-02-17
  • Resolved: 2021-02-17
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 17
17Resolved
Related Reports
Relates :  
JDK-8226690 - SIGSEGV in MetadataOnStackClosure::do_metadata
Description
Stress test fails during class redefinition with:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/scratch/opt/mach5/mesos/work_dir/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S39175/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d6ef31f0-93fd-4a03-8a4d-64b4107e9793/runs/16433c57-5075-427a-b92f-14755e61f73f/workspace/open/src/hotspot/share/oops/method.cpp:2135), pid=21021, tid=21053
#  assert(!value || !is_old() || is_obsolete() || is_running_emcp()) failed: emcp methods cannot run after emcp bit is cleared
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-2019-04-04-2151264.leonid.mesnik.ks-apps)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-2019-04-04-2151264.leonid.mesnik.ks-apps, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x125c3f4]  Method::set_on_stack(bool)+0xd4
#
# Core dump will be written. Default location: /scratch/opt/mach5/mesos/work_dir/slaves/2dd962d0-8988-479b-a804-57ab764ada59-S1363/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4be93dfd-b25a-4ab6-bcc9-c938df89dc71/runs/1f3c3b22-f2f2-467a-bd5d-445e3cd38dfb/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/core.21021
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -XX:MaxRAMPercentage=8 -Dkitchensink.modules.additional=Instrumentation -XX:MaxRAMPercentage=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:+DisplayVMOutputToStderr -XX:+UsePerfData -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+StartAttachListener -XX:NativeMemoryTracking=detail -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/scratch/opt/mach5/mesos/work_dir/slaves/2dd962d0-8988-479b-a804-57ab764ada59-S1363/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4be93dfd-b25a-4ab6-bcc9-c938df89dc71/runs/1f3c3b22-f2f2-467a-bd5d-445e3cd38dfb/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/java.io.tmpdir -Duser.home=/scratch/opt/mach5/mesos/work_dir/slaves/2dd962d0-8988-479b-a804-57ab764ada59-S1363/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4be93dfd-b25a-4ab6-bcc9-c938df89dc71/runs/1f3c3b22-f2f2-467a-bd5d-445e3cd38dfb/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/user.home -agentpath:/scratch/opt/mach5/mesos/work_dir/jib-master/install/2019-04-04-2151264.leonid.mesnik.ks-apps/linux-x64-debug.test/hotspot/jtreg/native/libJvmtiStressModule.so -Xverify:all -javaagent:redefineagent.jar applications.kitchensink.process.stress.Main /scratch/opt/mach5/mesos/work_dir/slaves/2dd962d0-8988-479b-a804-57ab764ada59-S1363/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4be93dfd-b25a-4ab6-bcc9-c938df89dc71/runs/1f3c3b22-f2f2-467a-bd5d-445e3cd38dfb/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/kitchensink.final.properties

Host: oracle.com, Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 6 cores, 29G, Oracle Linux Server release 7.1
Time: Thu Apr  4 15:25:04 2019 PDT elapsed time: 721 seconds (0d 0h 12m 1s)

---------------  T H R E A D  ---------------

Current thread (0x00007fc3b845a800):  VMThread "VM Thread" [stack: 0x00007fc37c28d000,0x00007fc37c38d000] [id=21053]

Stack: [0x00007fc37c28d000,0x00007fc37c38d000],  sp=0x00007fc37c38b740,  free space=1017k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x125c3f4]  Method::set_on_stack(bool)+0xd4
V  [libjvm.so+0x12d4d71]  nmethod::metadata_do(MetadataClosure*)+0x161
V  [libjvm.so+0x9373c8]  CodeCache::metadata_do(MetadataClosure*)+0x48
V  [libjvm.so+0x1241555]  MetadataOnStackMark::MetadataOnStackMark(bool, bool)+0x1d5
V  [libjvm.so+0x1089159]  VM_RedefineClasses::doit()+0x69
V  [libjvm.so+0x16ec3a3]  VM_Operation::evaluate()+0x143
V  [libjvm.so+0x171b95f]  VMThread::evaluate_operation(VM_Operation*) [clone .constprop.64]+0x17f
V  [libjvm.so+0x171c3d1]  VMThread::loop()+0x701
V  [libjvm.so+0x171c729]  VMThread::run()+0xb9
V  [libjvm.so+0x1635e96]  Thread::call_run()+0xf6
V  [libjvm.so+0x13574cd]  thread_native_entry(Thread*)+0x10d
Comments
This symptom was found in testing from April 6, 2019-Sept 18, 2019 and hasn't been seen since. This might be fixed by JDK-8226690. In any case, I can't reproduce it even on JDK 11 and the artifacts have been deleted. Closing as CNR.
17-02-2021
There's a Method pointer in the code cache that we didn't find on a previous walk of the code cache.
16-02-2021