JDK-8151403 : NSK JVMTI test jvmti/GetBytecodes/bytecodes003 SIGSEGV in Jvmti::post_class_prepare
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2016-03-07
  • Updated: 2016-12-19
  • Resolved: 2016-06-16
Related Reports
Relates :  
JDK-8151532 - Add support for module aware agents introduced regression for CompiledMethodLoad event
Relates :  
JDK-8151404 - NSK JVMTI test jvmti/unit/MethodBind/JvmtiTest failure within call to GetMethodDeclaringClass
Description
New test failure for the colocated tonga test jvmti/GetBytecodes/bytecodes003 in the Jigsaw/jake repo.  Test receives a SIGSEGV in JvmtiExport::post_class_prepare.

Possibly related to early VMStart support.
Comments
I'm closing bug this as WNF. The original problem is that the WRONG_PHASE error can come in the middle of the events handling. This impacts many tests, not only this one. There is a separate plan to fix the WRONG_PHASE problem in JVMTI, so that, it will be a waist of resources to improve the reliability of the nsk tests as a work around the original problem.
16-06-2016
Changed the priority to P4. The main issue was fixed by the JDK-8151404. This is the secondary issue to make the test more defensive to the possible return of the JVMTI_ERROR_WRONG_PHASE error. This issue even does not manifest itself and extremely rare reproducible. Also, the SQE is very reluctant to update the co-located nsk.jvmti tests as there is a plan to move under Jtreg framework.
27-04-2016
This issue is secondary and can be fixed in M4. The SIGSEGV happens only if it is triggered by the JVMTI_ERROR_WRONG_PHASE bug. The test jvmti/GetBytecodes/bytecodes003 will pass with the fix of the JDK-8151404: https://bugs.openjdk.java.net/browse/JDK-8151404
16-03-2016
The conclusion: 1-st issue: It looks like there is a mismatch in the phase calculation between the ClassLoad event post and the JVMTI functions GetClassSignature and GetClassMethods. It can be qualified as a manifestation of the bug: https://bugs.openjdk.java.net/browse/JDK-8151404 2-nd issue: The test itself must be modified to become defensive against the SISEGV. I'm suggesting to only fix the second issue as a part of this bug fix and leave the 1-st issue alone as a part of the JDK-8151404.
11-03-2016
There are a lot of error messages like the following: [2016-03-09T02:20:00.28] (GetClassSignature#0) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] (GetClassMethods#0) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] (GetMethodName) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] class: "(null)" [2016-03-09T02:20:00.28] (IsMethodNative) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] class: "(null)" [2016-03-09T02:20:00.28] method = "(null)(null)" [2016-03-09T02:20:00.28] (GetMethodName) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] class: "(null)" [2016-03-09T02:20:00.28] (IsMethodNative) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] class: "(null)" [2016-03-09T02:20:00.28] method = "(null)(null)" [2016-03-09T02:20:00.28] (GetMethodName) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] class: "(null)" [2016-03-09T02:20:00.28] (IsMethodNative) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] class: "(null)" [2016-03-09T02:20:00.28] method = "(null)(null)" [2016-03-09T02:20:00.28] (GetMethodName) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) [2016-03-09T02:20:00.28] class: "(null)" [2016-03-09T02:20:00.28] (IsMethodNative) unexpected error: JVMTI_ERROR_WRONG_PHASE (112) . . . . . . . . . . . . . . . . . . . All errors seems to be reported at the time of the ClassPrepare event posts. It is odd as the ClassPrepare event has to be posted in the START or LIVE phases only that has to be acceptable for the above JVMTI functions. The most relevant fragment of the hs_err dump: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f591e4cb7ad, pid=15901, tid=15911 # # JRE version: (9.0) (fastdebug build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-03-09-020043.christian.jake-nightly2, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libbytecodes003.so+0x57ad] ClassPrepare+0x152 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" (or dumping to /scratch/home/aurora/sandbox/results/ResultDir/bytecodes003/core.15901) # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- S U M M A R Y ------------ Command Line: -Xmixed -agentlib:bytecodes003 nsk.jvmti.GetBytecodes.bytecodes003 Host: scaaa119.us.oracle.com, Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 251G, Oracle Linux Server release 7.0 Time: Tue Mar 8 18:20:00 2016 PST elapsed time: 0 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x00007f5918018800): JavaThread "Unknown thread" [_thread_in_native, id=15911, stack(0x00007f592172b000,0x00007f592182c000)] Stack: [0x00007f592172b000,0x00007f592182c000], sp=0x00007f592182a560, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libbytecodes003.so+0x57ad] ClassPrepare+0x152 V [libjvm.so+0xe4b540] JvmtiExport::post_class_prepare(JavaThread*, Klass*)+0x1c0 V [libjvm.so+0xc12936] InstanceKlass::link_class_impl(instanceKlassHandle, bool, Thread*)+0x696 V [libjvm.so+0xc12415] InstanceKlass::link_class_impl(instanceKlassHandle, bool, Thread*)+0x175 V [libjvm.so+0xc15891] InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0xf1 V [libjvm.so+0xc159b9] InstanceKlass::initialize(Thread*)+0xe9 V [libjvm.so+0x1357d62] initialize_class(Symbol*, Thread*)+0xd2 V [libjvm.so+0x1366b08] Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x68 V [libjvm.so+0x1367b28] Threads::create_vm(JavaVMInitArgs*, bool*)+0x528 V [libjvm.so+0xd0519e] JNI_CreateJavaVM+0x8e C [libjli.so+0x71e3] JavaMain+0x83 C [libpthread.so.0+0x7df3] start_thread+0xc3 . . . . . . . . . . . . The failing top frame is the agent ClassPrepare event handler. The SIGSEGV issue is the test problem as the ClassPrepare event handler incorrectly handles the JVMTI_ERROR_WRONG_PHASE error. It does not return when a error is encountered and continues its execution and then tries to use the uninitialized values of the 'mcount' and 'methods' locals: 311 void JNICALL ClassPrepare(jvmtiEnv *jvmti_env, JNIEnv *env, 312 jthread thr, jclass cls) { 313 jvmtiError err; 314 char *sig, *name, *msig; 315 jint mcount; 316 jmethodID *methods; 317 jboolean isNative; 318 jint bytecodeCount; 319 unsigned char *bytecodes; 320 jint i; 321 322 sig = NULL; 323 err = (*jvmti_env)->GetClassSignature(jvmti_env, cls, &sig, NULL); 324 if (err != JVMTI_ERROR_NONE) { 325 printf("(GetClassSignature#%d) unexpected error: %s (%d)\n", 326 eventsCount, TranslateError(err), err); 327 result = FAILED; 328 } 329 err = (*jvmti_env)->GetClassMethods(jvmti_env, cls, &mcount, &methods); 330 if (err != JVMTI_ERROR_NONE) { 331 printf("(GetClassMethods#%d) unexpected error: %s (%d)\n", 332 eventsCount, TranslateError(err), err); 333 result = FAILED; 334 } 335 336 if (printdump == JNI_TRUE) { 337 printf(">>> [class prepare event #%d]", eventsCount); 338 printf(" \"%s\"\n", sig); 339 printf(">>> %d methods:\n", mcount); 340 } 341 342 for (i = 0; i < mcount; i++) { 343 if (methods[i] == NULL) { 344 if (printdump == JNI_TRUE) { 345 printf(" null"); 346 } 347 } else {
11-03-2016
Ok, I've found the following link can be used: https://jdash.se.oracle.com/nightlies/jake/
10-03-2016