JDK-8173361 : various crashes in JvmtiExport::post_compiled_method_load
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8,openjdk8u312,9,11,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-01-25
  • Updated: 2023-09-04
  • Resolved: 2019-12-02
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 11 JDK 13 JDK 14 JDK 8 Other
11.0.10-oracleFixed 13.0.6Fixed 14 b26Fixed 8u401Fixed openjdk8u352Fixed
Related Reports
Duplicate :  
JDK-8225226 - vmTestbase/nsk/jvmti/scenarios/hotswap/HS101/hs101t005 crashes in Method::checked_resolve_jmethod_id(jmethodID)
Duplicate :  
JDK-8202883 - crash in the JvmtiExport::post_compiled_method_load
Relates :  
JDK-8235218 - Minimal VM is broken after JDK-8173361
Relates :  
JDK-8181110 - jvmti/hotswap test crashes in Method::checked_resolve_jmethod_id(_jmethodID*)
Relates :  
JDK-7030041 - deferred CompiledMethodLoad events may have a stale oop problem
Relates :  
JDK-8235696 - ZGC: assert(ZNMethod::is_armed(nm) == _should_disarm_nmethods) failed: Invalid state
Relates :  
JDK-8212159 - assert(zombie_ok || !nm->is_zombie()) failed: cannot lock a zombie method
Relates :  
JDK-8305165 - [8u] ServiceThread::nmethods_do is not called to keep nmethods from being zombied while in the queue
Description
Trying to reproduce the linked bug on windows 32 bit, I got two crashes in this method:

DebugInfoReadStream::read_method()

Stack: [0x15020000,0x15070000],  sp=0x1506f828,  free space=318k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)

V  [jvm.dll+0x2b7669]  DebugInfoReadStream::read_method+0x39;;  ?read_method@DebugInfoReadStream@@QAEPAVMethod@@XZ+0x39
V  [jvm.dll+0x38a06e]  CompiledMethod::scope_desc_at+0xbe;;  ?scope_desc_at@CompiledMethod@@QAEPAVScopeDesc@@PAE@Z+0xbe
V  [jvm.dll+0x61b0c7]  create_inline_record+0x117;;  ?create_inline_record@@YAPAU_jvmtiCompiledMethodLoadInlineRecord@@PAVnmethod@@@Z+0x117
V  [jvm.dll+0x61c9cb]  JvmtiExport::post_compiled_method_load+0x13b;;  ?post_compiled_method_load@JvmtiExport@@SAXPAVnmethod@@@Z+0x13b
V  [jvm.dll+0x624a82]  JvmtiDeferredEvent::post+0x102;;  ?post@JvmtiDeferredEvent@@QAEXXZ+0x102
V  [jvm.dll+0x89179c]  JavaThread::thread_main_inner+0xcc;;  ?thread_main_inner@JavaThread@@QAEXXZ+0xcc
V  [jvm.dll+0x89095e]  JavaThread::run+0x18e;;  ?run@JavaThread@@UAEXXZ+0x18e
V  [jvm.dll+0x7765ab]  thread_native_entry+0x10b;;  ?thread_native_entry@@YGIPAVThread@@@Z+0x10b
C  [msvcr120.dll+0x2c01d]
C  [msvcr120.dll+0x2c001]
C  [KERNEL32.DLL+0x17c04]
C  [ntdll.dll+0x5ab8f]
C  [ntdll.dll+0x5ab5a]

This was out of 100 runs.
Comments
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk8u-dev/pull/9 Date: 2022-03-17 11:07:23 +0000
17-03-2022
Fix request (8u) Follow-up fix JDK-8235218 is planned to be backported as well. RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014487.html
05-01-2022
hi, we also encountered this problem on JDK8u312. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000ffff8e2f1498, pid=289495, tid=0x0000ffff70d641e0 # # JRE version: OpenJDK Runtime Environment (8.0_312-b07) (build 1.8.0_312-xxx_xxx_xxx) # Java VM: OpenJDK 64-Bit Server VM (25.312-b07 mixed mode linux-aarch64 compressed oops) # Problematic frame: # V [libjvm.so+0x807498] JvmtiExport::post_compiled_method_load(nmethod*)+0x6b0 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # # --------------- T H R E A D --------------- Current thread (0x0000aaaace357000): JavaThread "Service Thread" daemon [_thread_in_vm, id=289674, stack(0x0000ffff70d25000,0x0000ffff70d65000)] siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008 Registers: R0=0x0000aaaad84f60d0 R1=0x0000000000000000 R2=0x84e99a13d5fb1e00 R3=0x0000aaaad84f60d0 R4=0x0000ffff8ec58710 R5=0x0000000000000000 R6=0x00000000000000f4 R7=0x0000ffff63be6620 R8=0x0000000000000000 R9=0x0000000000000001 R10=0x0000ffff63be6620 R11=0x0000000000000002 R12=0x0000000000000000 R13=0x0000aaaace2b9a58 R14=0x0000aaaace2b9a60 R15=0x0000000000000000 R16=0x0000ffff8e992d30 R17=0x0000ffff8ebfe330 R18=0x0000000000000001 R19=0x0000aaaace357000 R20=0x0000aaaacfe66490 R21=0x0000aaaace357970 R22=0x0000ffff89d199d0 R23=0x0000ffff70d636d8 R24=0x0000aaaace2cd150 R25=0x0000ffff70d63650 R26=0x0000ffff70d648e0 R27=0x0000000000000000 R28=0x0000aaaace35b1a0 R29=0x0000ffff70d63590 R30=0x0000ffff8e2f0f80 Top of Stack: (sp=0x0000ffff70d63590) 0x0000ffff70d63590: 0000ffff70d63750 0000ffff8e2fbf14 0x0000ffff70d635a0: 0000ffff8ec58710 0000ffff89d199d0 0x0000ffff70d635b0: 0000ffff8ea06948 0000aaaacded78b0 0x0000ffff70d635c0: 0000aaaace3572c8 0000ffff8e9cd348 0x0000ffff70d635d0: 0000aaaace357000 0000000000000000 0x0000ffff70d635e0: 0000000000000000 0000ffff8e999000 0x0000ffff70d635f0: 0000aaaace2cd538 0000aaaace2cd160 0x0000ffff70d63600: 0000ffff8ec3cef0 0000ffff8e702e28 0x0000ffff70d63610: 00000001ce35b1a0 0000ffff70d636c0 0x0000ffff70d63620: 0000ffff70d63688 0000aaaace357000 0x0000ffff70d63630: 00000000000003d8 0000aaaace2cd538 0x0000ffff70d63640: 0000aaaace2cd160 0000aaaace2cd160 0x0000ffff70d63650: 0000aaaace357000 0000aaaace3579b0 0x0000ffff70d63660: 0000aaaace3579f0 0000aaaace357a00 0x0000ffff70d63670: 0000aaaace357ad8 00000000000000d8 0x0000ffff70d63680: 0000ffff70d638a0 0000aaaace357000 0x0000ffff70d63690: 0000aaaace357250 0000ffff8e2f0000 0x0000ffff70d636a0: 0000aaaad84f60d0 0000ffff70d63800 0x0000ffff70d636b0: 0000ffff8ea06948 0000aaaacded78b0 0x0000ffff70d636c0: 0000aaaace3572c8 0000ffff8e9cd348 0x0000ffff70d636d0: 0000aaaace357000 0000ffff6a7c5850 0x0000ffff70d636e0: 0000aaaace357970 0000aaaaddb706f0 0x0000ffff70d636f0: 0000aaaaddb73180 84e99a13d5fb1e00 0x0000ffff70d63700: 0000ffff70d63730 0000ffff8e2fc0e4 0x0000ffff70d63710: 0000ffff8e998000 0000aaaace3579b0 0x0000ffff70d63720: 0000ffff70d648e0 84e99a13d5fb1e00 0x0000ffff70d63730: 0000ffff70d63780 0000ffff8e572818 0x0000ffff70d63740: 0000000000000000 84e99a13d5fb1e00 0x0000ffff70d63750: 0000ffff70d63780 0000ffff8e5727c8 0x0000ffff70d63760: 0000000000000000 0000000000000001 0x0000ffff70d63770: 0000006800000008 84e99a13d5fb1e00 0x0000ffff70d63780: 0000ffff70d63850 0000ffff8e630db4 Instructions: (pc=0x0000ffff8e2f1498) 0x0000ffff8e2f1478: 00 00 40 f9 20 00 00 ca 60 34 00 b5 f3 53 41 a9 0x0000ffff8e2f1488: f6 17 40 f9 fa 27 40 f9 fd 7b dc a8 c0 03 5f d6 0x0000ffff8e2f1498: 60 07 40 f9 e1 03 17 aa 00 04 40 f9 07 0c 40 f9 0x0000ffff8e2f14a8: bf ff 14 a9 e0 03 07 aa 66 ca f9 97 aa a7 40 f9 Register to memory mapping: R0=0x0000aaaad84f60d0 R1=0x0000000000000000 R2=0x84e99a13d5fb1e00 R3=0x0000aaaad84f60d0 R4=0x0000ffff8ec58710 R5=0x0000000000000000 R6=0x00000000000000f4 R7=0x0000ffff63be6620 R8=0x0000000000000000 R9=0x0000000000000001 R10=0x0000ffff63be6620 R11=0x0000000000000002 R12=0x0000000000000000 R13=0x0000aaaace2b9a58 R14=0x0000aaaace2b9a60 R15=0x0000000000000000 R16=0x0000ffff8e992d30 R17=0x0000ffff8ebfe330 R18=0x0000000000000001 R19=0x0000aaaace357000 R20=0x0000aaaacfe66490 R21=0x0000aaaace357970 R22=0x0000ffff89d199d0 R23=0x0000ffff70d636d8 R24=0x0000aaaace2cd150 R25=0x0000ffff70d63650 R26=0x0000ffff70d648e0 R27=0x0000000000000000 R28=0x0000aaaace35b1a0 R29=0x0000ffff70d63590 R30=0x0000ffff8e2f0f80 Stack: [0x0000ffff70d25000,0x0000ffff70d65000], sp=0x0000ffff70d63590, free space=249k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x807498] JvmtiExport::post_compiled_method_load(nmethod*)+0x6b0 V [libjvm.so+0x811f14] JvmtiDeferredEvent::post()+0x7c V [libjvm.so+0xa887c8] ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x240 V [libjvm.so+0xb46db4] JavaThread::thread_main_inner()+0xf4 V [libjvm.so+0xb4701c] JavaThread::run()+0x214 V [libjvm.so+0x9bd9e4] java_start(Thread*)+0x11c C [libpthread.so.0+0x878c] C [libc.so.6+0xd514c]
17-12-2021
Fix request (13u) Requesting backport to 13u for parity with 11u. The patch doesn't apply cleanly due to minor context differences in serviceThread.hpp and mutexLocker.cpp (JDK-8170299 and JDK-8231472 are not in 13u), reapplied manually. Tested with tier1 and other jvmti tests. Follow-up fix JDK-8235218 is planned to be backported as well. RFR: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004661.html
18-01-2021
Fix request (11u) I would like to downport this for parity with 11.0.10-oracle. I had to resolve and adapt this: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004086.html
06-11-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/e79ece2eb1ba User: coleenp Date: 2019-12-02 13:42:41 +0000
02-12-2019
Yes, confirmed from the core file, that the class containing the nmethod that CompiledMethodLoad event has been unloaded: (gdb) print *nm $2 = {<CompiledMethod> = {<CodeBlob> = {_vptr.CodeBlob = 0x7f8319760558 <vtable for nmethod+16>, _type = compiler_c2, _size = 87200, ... _entry_bci = -1, _jmethod_id = 0x7f7b1047b4b8, _osr_link = 0x0, static claim_weak_request_tag = 0, ... (gdb) x /gx 0x7f7b1047b4b8 0x7f7b1047b4b8: 0x0000000000000000 jmethodIDs are cleared during class unloading: // Clear all the JNI handles for methods // These aren't deallocated and are going to look like a leak, but that's // needed because we can't really get rid of jmethodIDs because we don't // know when native code is going to stop using them. The spec says that // they're "invalid" but existing programs likely rely on their being // NULL after class unloading. if (_jmethod_ids != NULL) { Method::clear_jmethod_ids(this); }
15-11-2019
This can crash too with the deferred event in jvmtiExport.cpp: create_inline_record, because I think this code predated the JvmtiDeferredEvent change. for(ScopeDesc* sd = nm->scope_desc_at(p->real_pc(nm));sd != NULL;sd = sd->sender()) { // sd->method() can be NULL for stubs but not for nmethods. To be completely robust, include an assert that we should never see a null sd->method() assert(sd->method() != NULL, "sd->method() cannot be null."); record->pcinfo[scope].methods[stackframe] = sd->method()->jmethod_id(); <=method could be NULL or a bad pointer if the nmethod is unloaded record->pcinfo[scope].bcis[stackframe] = sd->bci(); stackframe++; }
13-11-2019
It looks like the nmethod is unloaded before it's posted from the JvmtiDeferredEvent, which makes sense. (gdb) print *nm $2 = {<CompiledMethod> = {<CodeBlob> = {_vptr.CodeBlob = 0x7f8319760558 <vtable for nmethod+16>, _type = compiler_c2, _size = 87200, _header_size = 352, _frame_complete_offset = 31, _data_offset = 37224, _frame_size = 72, ... _mark_for_deoptimization_status = CompiledMethod::deoptimize, _is_far_code = false, _has_unsafe_access = 0, _has_method_handle_invokes = 0, _lazy_critical_native = 0, _has_wide_vectors = 0, _method = 0x0, ... _comp_level = 4, _has_flushed_dependencies = true, _unload_reported = true, _state = 3 '\003', _rtm_state = NoRTM, _lock_count = 2, _stack_traversal_mark = 0, _hotness_counter = 480, _is_unloading_state = 7 '\a', The nmethodLocker doesn't keep it from being unloaded. From the stack nmethod->_method is NULL because it's been unloaded, and this code fails because the jmethodID is created from the method->method_holder()->class_loader_data() JNIMethodBlock area. The post_compiled_method_load code seems to be aware that the nmethod->_method field can be null, so the to_jmethodID function probably got broken with the changes to JNIMethodBlock per class loader data.
13-11-2019
Slightly different info for the JDK14 sighting, but still a problem in JvmtiExport::post_compiled_method_load()... # SIGSEGV (0xb) at pc=0x00007f97ef76bfc4, pid=11037, tid=11295 # # JRE version: Java(TM) SE Runtime Environment (14.0+6) (fastdebug build 14-ea+6-144) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-ea+6-144, compiled mode, sharing, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x155ffc4] ScopeDesc::decode_body()+0x254 --------------- T H R E A D --------------- Current thread (0x00007f97e84e3000): JavaThread "Service Thread" daemon [_thread_in_vm, id=11295, stack(0x00007f97b862f000,0x00007f97b8730000)] Stack: [0x00007f97b862f000,0x00007f97b8730000], sp=0x00007f97b872e870, free space=1022k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x155ffc4] ScopeDesc::decode_body()+0x254 V [libjvm.so+0x9e5216] CompiledMethod::scope_desc_at(unsigned char*)+0x106 V [libjvm.so+0x1103b22] create_inline_record(nmethod*)+0x1a2 V [libjvm.so+0x1103f89] JvmtiExport::post_compiled_method_load(JvmtiEnv*, nmethod*)+0xb9 V [libjvm.so+0x110420b] JvmtiExport::post_compiled_method_load(nmethod*)+0x5b V [libjvm.so+0x11111ec] JvmtiDeferredEvent::post()+0xdc V [libjvm.so+0x15625f3] ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x453 V [libjvm.so+0x16d000a] JavaThread::thread_main_inner()+0x26a V [libjvm.so+0x16d86f7] JavaThread::run()+0x227 V [libjvm.so+0x16d5766] Thread::call_run()+0xf6 V [libjvm.so+0x13f25ee] thread_native_entry(Thread*)+0x10e siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000
11-07-2019
The issue has been observed in JDK 13: # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0xffffffff7d1ac104, pid=58503, tid=18 # # JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-jdk13-jdk.129) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-jdk13-jdk.129, compiled mode, g1 gc, solaris-sparc) # Problematic frame: # V [libjvm.so+0x11ac104] Method*DebugInfoReadStream::read_method()+0x74 # # Core dump will be written. Default location: /scratch/opt/mach5/mesos/work_dir/dc63ae34-ffa5-498c-bd82-87004b01bdc5/testOutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/core or core.58503 # # 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=2 -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops -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/dc63ae34-ffa5-498c-bd82-87004b01bdc5/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/dc63ae34-ffa5-498c-bd82-87004b01bdc5/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/jdk13-jdk.129/solaris-sparcv9-debug.test/hotspot/jtreg/native/libJvmtiStressModule.so applications.kitchensink.process.stress.Main /scratch/opt/mach5/mesos/work_dir/dc63ae34-ffa5-498c-bd82-87004b01bdc5/testOutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/kitchensink.final.properties Host: slc08giw, Sparcv9 64 bit 3600 MHz, 56 cores, 58G, Oracle Solaris 11.3 SPARC Time: Wed Jan 16 07:08:24 2019 UTC elapsed time: 448 seconds (0d 0h 7m 28s) --------------- T H R E A D --------------- Current thread (0x00000001024dc800): JavaThread "Service Thread" daemon [_thread_in_vm, id=18, stack(0xffffffff56900000,0xffffffff56a00000)] Stack: [0xffffffff56900000,0xffffffff56a00000], sp=0xffffffff569ff310, free space=1020k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11ac104] Method*DebugInfoReadStream::read_method()+0x74 V [libjvm.so+0x219f518] void ScopeDesc::decode_body()+0x88 V [libjvm.so+0x13b7ce4] ScopeDesc*CompiledMethod::scope_desc_at(unsigned char*)+0x114 V [libjvm.so+0x1d114ec] _jvmtiCompiledMethodLoadInlineRecord*create_inline_record(nmethod*)+0x18c V [libjvm.so+0x1d11af0] void JvmtiExport::post_compiled_method_load(nmethod*)+0x360 V [libjvm.so+0x1d243d4] void JvmtiDeferredEvent::post()+0xa4 V [libjvm.so+0x21a2748] void ServiceThread::service_thread_entry(JavaThread*,Thread*)+0x508 V [libjvm.so+0x2380870] void JavaThread::thread_main_inner()+0x2c0 V [libjvm.so+0x237929c] void Thread::call_run()+0x1ec V [libjvm.so+0x20232e4] thread_native_entry+0x3e4 siginfo: si_signo: 10 (SIGBUS), si_code: 1 (BUS_ADRALN), si_addr: 0xbaadfadebaadfaee Register to memory mapping: G1=0x0000000000684e54 is an unknown value G2=0xffffffffffffffff is an unknown value G3=0x0000000b80d2a5c8 is an unknown value G4=0xffffffff7e668d30: __1cQMetaspaceClosurePPointerArrayRef4nFArray4CC___G__vtbl_+0x70 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 G5=0x0000000100000020: _START_+0x20 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/bin/java at 0x0000000100000000 G6=0x0 is NULL G7=0xffffffff79f08a40 points into unknown readable memory: 00 00 00 00 00 00 00 00 O0=0xfffffff7ffd23640 is pointing into metadata O1=0x0000000000000002 is an unknown value O2=0xffffffff7df9f990: __1cHnmethodQmetadata_addr_at6kMi_ppnIMetadata__+0 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 O3=0xffffffff7e6fc598: __1cHnmethodG__vtbl_+0 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 O4=0xffffffff7c792238: _DYNAMIC+0x7920c0 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 O5=0x000000010079df98 points into unknown readable memory: ff ff ff fe ff 86 20 6e O6=0xffffffff569feb11 is pointing into the stack for thread: 0x00000001024dc800 O7=0xffffffff7d1ac0f0: __1cTDebugInfoReadStreamLread_method6M_pnGMethod__+0x60 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 L0=0xffffffff7e6247e8: _GLOBAL_OFFSET_TABLE_+0 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 L1=0x000000010079df50 points into unknown readable memory: 00 00 00 00 00 00 00 00 L2=0xbaadfadebaadfade is an unknown value L3=0x0 is NULL L4=0xffffffff6faaa010 is at entry_point+-464 in (nmethod*)0xffffffff6faaa010 L5=0xffffffff6faaa420 is at entry_point+576 in (nmethod*)0xffffffff6faaa010 L6=0x0000000000000002 is an unknown value L7=0x0000000000000003 is an unknown value I0=0xfffffff7ffd23640 is pointing into metadata I1=0xffffffff6faaa010 is at entry_point+-464 in (nmethod*)0xffffffff6faaa010 I2=0x000000010079df90 points into unknown readable memory: ff ff ff ff 7e 67 d3 70 I3=0x0000000000000002 is an unknown value I4=0x0000000000000002 is an unknown value I5=0xffffffff7e6247e8: _GLOBAL_OFFSET_TABLE_+0 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 I6=0xffffffff569febc1 is pointing into the stack for thread: 0x00000001024dc800 I7=0xffffffff7e19f510: __1cJScopeDescLdecode_body6M_v_+0x80 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 Registers: G1=0x0000000000684e54 G2=0xffffffffffffffff G3=0x0000000b80d2a5c8 G4=0xffffffff7e668d30 G5=0x0000000100000020 G6=0x0000000000000000 G7=0xffffffff79f08a40 Y=0x0000000000000000 O0=0xfffffff7ffd23640 O1=0x0000000000000002 O2=0xffffffff7df9f990 O3=0xffffffff7e6fc598 O4=0xffffffff7c792238 O5=0x000000010079df98 O6=0xffffffff569feb11 O7=0xffffffff7d1ac0f0 L0=0xffffffff7e6247e8 L1=0x000000010079df50 L2=0xbaadfadebaadfade L3=0x0000000000000000 L4=0xffffffff6faaa010 L5=0xffffffff6faaa420 L6=0x0000000000000002 L7=0x0000000000000003 I0=0xfffffff7ffd23640 I1=0xffffffff6faaa010 I2=0x000000010079df90 I3=0x0000000000000002 I4=0x0000000000000002 I5=0xffffffff7e6247e8 I6=0xffffffff569febc1 I7=0xffffffff7e19f510 PC=0xffffffff7d1ac104 nPC=0xffffffff7d1ac108 Top of Stack: (sp=0xffffffff569ff310) 0xffffffff569ff310: ffffffff7e6247e8 000000010079df50 0xffffffff569ff320: baadfadebaadfade 0000000000000000 0xffffffff569ff330: ffffffff6faaa010 ffffffff6faaa420 0xffffffff569ff340: 0000000000000002 0000000000000003 0xffffffff569ff350: fffffff7ffd23640 ffffffff6faaa010 0xffffffff569ff360: 000000010079df90 0000000000000002 0xffffffff569ff370: 0000000000000002 ffffffff7e6247e8 0xffffffff569ff380: ffffffff569febc1 ffffffff7e19f510 0xffffffff569ff390: 0000000000000000 00000000001d2800 0xffffffff569ff3a0: ffffffff569ffb40 ffffffff7e380870 0xffffffff569ff3b0: 0000000000000000 0000000200001800 0xffffffff569ff3c0: 0000000000000000 ffffffff7e70e3e8 0xffffffff569ff3d0: ffffffff7e6247e8 0000000000000570 0xffffffff569ff3e0: ffffffffffffffff 000000010079df41 0xffffffff569ff3f0: ffffffff6faaa420 0000000000000001 0xffffffff569ff400: 000000010079df40 0000000000000001 Instructions: (pc=0xffffffff7d1ac104) 0xffffffff7d1ac0e4: b8 10 00 08 f0 5b e1 48 93 3f 20 00 9f c6 00 00 0xffffffff7d1ac0f4: 90 10 00 19 02 c2 00 19 b0 10 00 08 e4 5a 20 00 0xffffffff7d1ac104: e2 5c a0 10 9f c4 40 00 01 00 00 00 80 90 00 08 0xffffffff7d1ac114: 12 40 00 12 01 00 00 00 40 0b 72 55 29 00 78 25 Stack slot to memory mapping: stack at sp + 0 slots: 0xffffffff7e6247e8: _GLOBAL_OFFSET_TABLE_+0 in /scratch/opt/mach5/mesos/work_dir/jib-master/install/jdk13-jdk.129/solaris-sparcv9-debug.jdk/jdk-13/fastdebug/lib/server/libjvm.so at 0xffffffff7c000000 stack at sp + 1 slots: 0x000000010079df50 points into unknown readable memory: 00 00 00 00 00 00 00 00 stack at sp + 2 slots: 0xbaadfadebaadfade is an unknown value stack at sp + 3 slots: 0x0 is NULL stack at sp + 4 slots: 0xffffffff6faaa010 is at entry_point+-464 in (nmethod*)0xffffffff6faaa010 stack at sp + 5 slots: 0xffffffff6faaa420 is at entry_point+576 in (nmethod*)0xffffffff6faaa010 stack at sp + 6 slots: 0x0000000000000002 is an unknown value stack at sp + 7 slots: 0x0000000000000003 is an unknown value
16-01-2019
Looking at the history of this failure, I only see this specific failure happening twice, and both are on the same RBT run submitted by Coleen. I've run this test 100s of times on windows recently, and this crash never popped up. I suggest we close it a CNR.
05-05-2017