JDK-8078653 : demo/jvmti/heapTracker: assert(resolved_method->method_holder()->is_linked()) failed: must be linked
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8u45,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2015-04-27
  • Updated: 2015-05-04
  • Resolved: 2015-05-01
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
8u60Resolved
Related Reports
Relates :  
Description
If you download 8u45, and then also download the 8u45 demos, and then try to run heapTracker demo, then you will crash with:

$ ~/Install/jdk1.8.0_45/bin/java -agentpath:./lib/libheapTracker.so Hello
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000000, pid=25090, tid=140547090478848
#
# JRE version:  (8.0_45-b14) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  0x0000000000000000
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/shade/temp/jdk1.8.0_45/demo/jvmti/heapTracker/hs_err_pid25090.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)


...running the same with latest jdk9-dev fastdebug reveals:

$ ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java -agentpath:./lib/libheapTracker.so Hello
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/linkResolver.cpp:1180
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/trunks/jdk9-dev/hotspot/src/share/vm/interpreter/linkResolver.cpp:1180), pid=25103, tid=139757890959104
#  assert(resolved_method->method_holder()->is_linked()) failed: must be linked
#
# JRE version:  (9.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (1.9.0-internal-fastdebug-shade_2015_04_21_21_59-b00 mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/shade/temp/jdk1.8.0_45/demo/jvmti/heapTracker/core.25103)
#
# An error report file with more information is saved as:
# /home/shade/temp/jdk1.8.0_45/demo/jvmti/heapTracker/hs_err_pid25103.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 139757890959104
Dumping core ...
Aborted (core dumped)

Surprisingly, running jdk9-dev-fastdebug with jdk9-dev built demos is fine.
Running 8u45 with jdk9-dev built demos triggers the same crash.

(Initially assigned to hotspot/jvmti, looks like a demo issue)
Comments
The test with an incorrect classpath crashes because the agent VMStart callback is trying to load an agent class that is not on the classpath. It is the responsibility of the agent to be careful in the callbacks especially in the VMStart event when the VM has not finished the initialization yet. The ClassNotFoundException thrown by the VMStart callback changed the VM initialization (system classes loading) sequence and forced this situation with the assert with the unlinked class. This is the reason to close this issue as "Not an issue". If you still think that the VM can handle this situation better then the bug can be reopened and moved to the hotspot/runtime. However, there is no jvmti issue here anyway.
04-05-2015

In the simplified test case, java.lang.Thread is initialized with JNI_FindClass. During initialization of this class, we call a java.lang.String length on an instance of a string. Unfortunately, the JVM during initialization creates instances of String, Class and Throwables without actually linking and initializing the classes. I still think we should initialize these before creating agents. Or we could add an error to linkResolver like: philli% java -agentpath:./libagent.so -version Loaded C++ agent! C++: VM start Error occurred during initialization of VM length is called before java/lang/String is initialized But I'm not sure how helpful this message is since the user has no idea why java/lang/String isn't initialized (or why it shouldn't be initialized at this point which might be risky)
01-05-2015

The simplified test case crashes.
01-05-2015

I do not see this bug. Everything works fine for both 8u45 and 9: sspitsyn@j1-nehalem setenv JAVA_HOME /java/re/jdk/1.8.0_45/latest/binaries/solaris-amd64/fastdebug sspitsyn@j1-nehalem $JAVA_HOME/bin/java -agentpath:$JAVA_HOME/demo/jvmti/heapTracker/lib/libheapTracker.so \ ? -classpath .:$JAVA_HOME/demo/jvmti/heapTracker/heapTracker.jar Hello Hello, World Dumping heap trace information 1: 232680 bytes 4757 objects 3573 live before VM_INIT stack=<empty> 2: 95616 bytes 381 objects 381 live stack=(Lsun/util/calendar/ZoneInfoFile;.load@141[ZoneInfoFile.java:318],Lsun/util/calendar/ZoneInfoFile;.access$000@1[ZoneInfoFile.java:61],Lsun/util/calendar/ZoneInfoFile$1;.run@65[ZoneInfoFile.java:258],Ljava/security/AccessController;.doPrivileged@-1[AccessController.java:0],Lsun/util/calendar/ZoneInfoFile;.<clinit>@633[ZoneInfoFile.java:251],Lsun/util/calendar/ZoneInfo;.getTimeZone@1[ZoneInfo.java:589]) nframes=6 3: 29704 bytes 585 objects 585 live unknown stack=<empty> 4: 28152 bytes 589 objects 589 live stack=(Ljava/util/Arrays;.copyOfRange@43[Arrays.java:3664],Ljava/lang/String;.<init>@55[String.java:201],Ljava/io/DataInputStream;.readUTF@513[DataInputStream.java:661],Ljava/io/DataInputStream;.readUTF@1[DataInputStream.java:564],Lsun/util/calendar/ZoneInfoFile;.load@96[ZoneInfoFile.java:312],Lsun/util/calendar/ZoneInfoFile;.access$000@1[ZoneInfoFile.java:61]) nframes=6 5: 14136 bytes 589 objects 589 live stack=(Ljava/lang/Object;.<init>@1[Object.java:37],Ljava/lang/String;.<init>@1[String.java:190],Ljava/io/DataInputStream;.readUTF@513[DataInputStream.java:661],Ljava/io/DataInputStream;.readUTF@1[DataInputStream.java:564],Lsun/util/calendar/ZoneInfoFile;.load@96[ZoneInfoFile.java:312],Lsun/util/calendar/ZoneInfoFile;.access$000@1[ZoneInfoFile.java:61]) nframes=6 6: 3584 bytes 112 objects 112 live stack=(Ljava/lang/Object;.<init>@1[Object.java:37],Ljava/util/HashMap$Node;.<init>@1[HashMap.java:284],Ljava/util/HashMap;.newNode@9[HashMap.java:1734],Ljava/util/HashMap;.putVal@56[HashMap.java:630],Ljava/util/HashMap;.put@9[HashMap.java:611],Lsun/util/calendar/ZoneInfoFile;.load@314[ZoneInfoFile.java:341]) nframes=6 7: 2752 bytes 86 objects 86 live stack=(Ljava/lang/Object;.<init>@1[Object.java:37],Ljava/util/HashMap$Node;.<init>@1[HashMap.java:284],Ljava/util/HashMap;.newNode@9[HashMap.java:1734],Ljava/util/HashMap;.putVal@152[HashMap.java:641],Ljava/util/HashMap;.put@9[HashMap.java:611],Lsun/util/calendar/ZoneInfoFile;.load@314[ZoneInfoFile.java:341]) nframes=6 8: 2632 bytes 7 objects 7 live stack=(Ljava/lang/Object;.<init>@1[Object.java:37],Ljava/lang/Thread;.<init>@1[Thread.java:531]) nframes=2 9: 2624 bytes 11 objects 11 live stack=(Ljava/util/Arrays;.copyOfRange@43[Arrays.java:3664],Ljava/lang/String;.<init>@55[String.java:201],Ljava/lang/StringBuilder;.toString@13[StringBuilder.java:407],Lsun/net/util/URLUtil;.urlNoFragString@110[URLUtil.java:80],Lsun/misc/URLClassPath;.getLoader@67[URLClassPath.java:485],Lsun/misc/URLClassPath;.getNextLoader@84[URLClassPath.java:457]) nframes=6 10: 2536 bytes 10 objects 10 live stack=(Ljava/util/Arrays;.copyOfRange@43[Arrays.java:3664],Ljava/lang/String;.<init>@55[String.java:201],Ljava/lang/StringBuilder;.toString@13[StringBuilder.java:407],Lsun/misc/URLClassPath$JarLoader;.<init>@26[URLClassPath.java:775],Lsun/misc/URLClassPath$3;.run@82[URLClassPath.java:530],Lsun/misc/URLClassPath$3;.run@1[URLClassPath.java:520]) nframes=6 11: 2376 bytes 1 objects 1 live stack=(Lsun/util/calendar/ZoneInfoFile;.load@185[ZoneInfoFile.java:325],Lsun/util/calendar/ZoneInfoFile;.access$000@1[ZoneInfoFile.java:61],Lsun/util/calendar/ZoneInfoFile$1;.run@65[ZoneInfoFile.java:258],Ljava/security/AccessController;.doPrivileged@-1[AccessController.java:0],Lsun/util/calendar/ZoneInfoFile;.<clinit>@633[ZoneInfoFile.java:251],Lsun/util/calendar/ZoneInfo;.getTimeZone@1[ZoneInfo.java:589]) nframes=6 12: 2376 bytes 1 objects 1 live stack=(Lsun/util/calendar/ZoneInfoFile;.load@195[ZoneInfoFile.java:326],Lsun/util/calendar/ZoneInfoFile;.access$000@1[ZoneInfoFile.java:61],Lsun/util/calendar/ZoneInfoFile$1;.run@65[ZoneInfoFile.java:258],Ljava/security/AccessController;.doPrivileged@-1[AccessController.java:0],Lsun/util/calendar/ZoneInfoFile;.<clinit>@633[ZoneInfoFile.java:251],Lsun/util/calendar/ZoneInfo;.getTimeZone@1[ZoneInfo.java:589]) nframes=6 13: 2064 bytes 5 objects 1 live stack=(Ljava/util/HashMap;.resize@137[HashMap.java:703],Ljava/util/HashMap;.putVal@288[HashMap.java:662],Ljava/util/HashMap;.put@9[HashMap.java:611],Lsun/util/calendar/ZoneInfoFile;.load@314[ZoneInfoFile.java:341],Lsun/util/calendar/ZoneInfoFile;.access$000@1[ZoneInfoFile.java:61],Lsun/util/calendar/ZoneInfoFile$1;.run@65[ZoneInfoFile.java:258]) nframes=6 14: 1544 bytes 1 objects 1 live stack=(Lsun/util/calendar/ZoneInfoFile;.load@118[ZoneInfoFile.java:316],Lsun/util/calendar/ZoneInfoFile;.access$000@1[ZoneInfoFile.java:61],Lsun/util/calendar/ZoneInfoFile$1;.run@65[ZoneInfoFile.java:258],Ljava/security/AccessController;.doPrivileged@-1[AccessController.java:0],Lsun/util/calendar/ZoneInfoFile;.<clinit>@633[ZoneInfoFile.java:251],Lsun/util/calendar/ZoneInfo;.getTimeZone@1[ZoneInfo.java:589]) nframes=6 15: 1040 bytes 1 objects 1 live stack=(Ljava/lang/invoke/MethodHandleImpl;.<clinit>@109[MethodHandleImpl.java:1514],Ljava/lang/invoke/MethodHandle;.<clinit>@16[MethodHandle.java:422]) nframes=2 16: 648 bytes 1 objects 1 live stack=(Ljava/util/zip/InflaterInputStream;.<init>@84[InflaterInputStream.java:88],Ljava/util/zip/ZipFile$ZipFileInflaterInputStream;.<init>@10[ZipFile.java:394],Ljava/util/zip/ZipFile;.getInputStream@239[ZipFile.java:375],Ljava/util/jar/JarFile;.getBytes@2[JarFile.java:424],Ljava/util/jar/JarFile;.checkForSpecialAttributes@26[JarFile.java:555],Ljava/util/jar/JarFile;.hasClassPathAttribute@1[JarFile.java:518]) nframes=6 17: 640 bytes 10 objects 10 live stack=(Ljava/lang/Object;.<init>@1[Object.java:37],Ljava/net/URL;.<init>@1[URL.java:369],Lsun/misc/URLClassPath$JarLoader;.<init>@30[URLClassPath.java:775],Lsun/misc/URLClassPath$3;.run@82[URLClassPath.java:530],Lsun/misc/URLClassPath$3;.run@1[URLClassPath.java:520],Ljava/security/AccessController;.doPrivileged@-1[AccessController.java:0]) nframes=6 18: 576 bytes 18 objects 18 live stack=(Ljava/lang/Object;.<init>@1[Object.java:37],Ljava/util/HashMap$Node;.<init>@1[HashMap.java:284],Ljava/util/HashMap;.newNode@9[HashMap.java:1734],Ljava/util/HashMap;.putVal@56[HashMap.java:630],Ljava/util/HashMap;.put@9[HashMap.java:611],Lsun/util/calendar/ZoneInfoFile;.addOldMapping@27[ZoneInfoFile.java:270]) nframes=6 19: 528 bytes 1 objects 1 live stack=(Ljava/util/jar/JarFile;.<clinit>@81[JarFile.java:476],Lsun/misc/URLClassPath$JarLoader;.getJarFile@36[URLClassPath.java:893],Lsun/misc/URLClassPath$JarLoader;.access$700@2[URLClassPath.java:756],Lsun/misc/URLClassPath$JarLoader$1;.run@55[URLClassPath.java:838],Lsun/misc/URLClassPath$JarLoader$1;.run@1[URLClassPath.java:831],Ljava/security/AccessController;.doPrivileged@-1[AccessController.java:0]) nframes=6 20: 528 bytes 1 objects 1 live stack=(Ljava/util/zip/InflaterInputStream;.<init>@38[InflaterInputStream.java:187],Ljava/util/zip/ZipFile$ZipFileInflaterInputStream;.<init>@10[ZipFile.java:394],Ljava/util/zip/ZipFile;.getInputStream@239[ZipFile.java:375],Ljava/util/jar/JarFile;.getBytes@2[JarFile.java:424],Ljava/util/jar/JarFile;.checkForSpecialAttributes@26[JarFile.java:555],Ljava/util/jar/JarFile;.hasClassPathAttribute@1[JarFile.java:518]) nframes=6 sspitsyn@j1-nehalem setenv JAVA_HOME /java/re/jdk/1.9.0/latest/binaries/solaris-amd64/fastdebug sspitsyn@j1-nehalem $JAVA_HOME/bin/java -agentpath:$JAVA_HOME/demo/jvmti/heapTracker/lib/libheapTracker.so \ ? -classpath .:$JAVA_HOME/demo/jvmti/heapTracker/heapTracker.jar Hello Hello, World Dumping heap trace information 1: 241256 bytes 4902 objects 4008 live before VM_INIT stack=<empty> 2: 88456 bytes 1148 objects 1142 live stack=(Ljava/lang/StringCoding;.decode@22[StringCoding.java:215],Ljava/lang/String;.<init>@31[String.java:468],Ljdk/internal/jimage/UTF8String;.toString@19[UTF8String.java:228],Ljdk/internal/jimage/BasicImageReader;.getString@8[BasicImageReader.java:201],Ljdk/internal/jimage/BasicImageReader;.getNames@33[BasicImageReader.java:234],Ljdk/internal/jimage/BasicImageReader;.getNames@6[BasicImageReader.java:225]) nframes=6 3: 27408 bytes 1148 objects 1142 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/lang/String;.<init>@1[String.java:464],Ljdk/internal/jimage/UTF8String;.toString@19[UTF8String.java:228],Ljdk/internal/jimage/BasicImageReader;.getString@8[BasicImageReader.java:201],Ljdk/internal/jimage/BasicImageReader;.getNames@33[BasicImageReader.java:234],Ljdk/internal/jimage/BasicImageReader;.getNames@6[BasicImageReader.java:225]) nframes=6 4: 25408 bytes 430 objects 430 live unknown stack=<empty> 5: 21408 bytes 669 objects 669 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/util/HashMap$Node;.<init>@1[HashMap.java:284],Ljava/util/HashMap;.newNode@9[HashMap.java:1786],Ljava/util/HashMap;.putVal@56[HashMap.java:630],Ljava/util/HashMap;.put@9[HashMap.java:611],Ljdk/internal/jimage/PackageModuleMap;.readFrom@109[PackageModuleMap.java:57]) nframes=6 6: 14240 bytes 445 objects 445 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/util/HashMap$Node;.<init>@1[HashMap.java:284],Ljava/util/HashMap;.newNode@9[HashMap.java:1786],Ljava/util/HashMap;.putVal@152[HashMap.java:641],Ljava/util/HashMap;.put@9[HashMap.java:611],Ljdk/internal/jimage/PackageModuleMap;.readFrom@109[PackageModuleMap.java:57]) nframes=6 7: 10272 bytes 12 objects 2 live stack=(Ljava/util/HashMap;.resize@137[HashMap.java:703],Ljava/util/HashMap;.putVal@288[HashMap.java:662],Ljava/util/HashMap;.put@9[HashMap.java:611],Ljdk/internal/jimage/PackageModuleMap;.readFrom@109[PackageModuleMap.java:57],Ljdk/internal/jimage/ImageReader;.<init>@8[ImageReader.java:67],Ljdk/internal/jimage/ImageReader;.open@6[ImageReader.java:76]) nframes=6 8: 3008 bytes 8 objects 8 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/lang/Thread;.<init>@1[Thread.java:531]) nframes=2 9: 1040 bytes 1 objects 1 live stack=(Ljava/lang/invoke/MethodHandleImpl;.<clinit>@109[MethodHandleImpl.java:1571],Ljava/lang/invoke/MethodHandle;.<clinit>@16[MethodHandle.java:422]) nframes=2 10: 704 bytes 3 objects 3 live stack=(Ljava/util/Arrays;.copyOfRange@43[Arrays.java:3664],Ljava/lang/String;.<init>@75[String.java:211],Ljava/lang/StringBuilder;.toString@13[StringBuilder.java:407],Ljava/io/UnixFileSystem;.canonicalize@127[UnixFileSystem.java:167],Ljava/io/File;.getCanonicalPath@27[File.java:618],Ljava/lang/ClassLoader$3;.run@14[ClassLoader.java:1873]) nframes=6 11: 704 bytes 3 objects 3 live stack=(Ljava/util/Arrays;.copyOfRange@43[Arrays.java:3664],Ljava/lang/String;.<init>@75[String.java:211],Ljava/lang/StringBuilder;.toString@13[StringBuilder.java:407],Ljava/io/UnixFileSystem;.canonicalize@96[UnixFileSystem.java:166],Ljava/io/File;.getCanonicalPath@27[File.java:618],Ljava/lang/ClassLoader$3;.run@14[ClassLoader.java:1873]) nframes=6 12: 632 bytes 3 objects 3 live stack=(Ljava/util/Arrays;.copyOfRange@43[Arrays.java:3664],Ljava/lang/String;.<init>@75[String.java:211],Ljava/lang/StringBuilder;.toString@13[StringBuilder.java:407],Lsun/net/util/URLUtil;.urlNoFragString@110[URLUtil.java:77],Lsun/misc/URLClassPath;.getLoader@67[URLClassPath.java:346],Lsun/misc/URLClassPath;.getResource@42[URLClassPath.java:219]) nframes=6 13: 400 bytes 10 objects 10 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/lang/ref/Reference;.<init>@1[Reference.java:307],Ljava/lang/ref/PhantomReference;.<init>@3[PhantomReference.java:80],Lsun/misc/Cleaner;.<init>@5[Cleaner.java:115],Lsun/misc/Cleaner;.create@12[Cleaner.java:133],Ljava/nio/DirectByteBuffer;.<init>@19[DirectByteBuffer.java:179]) nframes=6 14: 384 bytes 6 objects 6 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/nio/Buffer;.<init>@1[Buffer.java:197],Ljava/nio/ByteBuffer;.<init>@6[ByteBuffer.java:281],Ljava/nio/ByteBuffer;.<init>@8[ByteBuffer.java:289],Ljava/nio/MappedByteBuffer;.<init>@6[MappedByteBuffer.java:89],Ljava/nio/DirectByteBuffer;.<init>@5[DirectByteBuffer.java:162]) nframes=6 15: 336 bytes 3 objects 3 live stack=(Ljava/lang/StringCoding$StringDecoder;.decode@18[StringCoding.java:149],Ljava/lang/StringCoding;.decode@116[StringCoding.java:193],Ljava/lang/String;.<init>@31[String.java:431],Ljava/lang/String;.<init>@6[String.java:496],Ljava/io/UnixFileSystem;.canonicalize0@-1[UnixFileSystem.java:0],Ljava/io/UnixFileSystem;.canonicalize@140[UnixFileSystem.java:172]) nframes=6 16: 336 bytes 6 objects 6 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/nio/Buffer;.<init>@1[Buffer.java:197],Ljava/nio/LongBuffer;.<init>@6[LongBuffer.java:281],Ljava/nio/LongBuffer;.<init>@8[LongBuffer.java:289],Ljava/nio/DirectLongBufferU;.<init>@7[DirectLongBufferU.java:195],Ljava/nio/DirectByteBuffer;.asLongBuffer@129[DirectByteBuffer.java:832]) nframes=6 17: 320 bytes 10 objects 10 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/util/concurrent/ConcurrentHashMap$Node;.<init>@1[ConcurrentHashMap.java:625],Ljava/util/concurrent/ConcurrentHashMap;.putVal@92[ConcurrentHashMap.java:1019],Ljava/util/concurrent/ConcurrentHashMap;.putIfAbsent@4[ConcurrentHashMap.java:1535],Ljava/lang/ClassLoader;.getClassLoadingLock@23[ClassLoader.java:462],Ljava/lang/ClassLoader;.loadClass@2[ClassLoader.java:403]) nframes=6 18: 288 bytes 6 objects 5 live stack=(Ljava/util/Arrays;.copyOfRange@43[Arrays.java:3664],Ljava/lang/String;.<init>@75[String.java:211],Ljava/lang/StringBuilder;.toString@13[StringBuilder.java:407],Ljava/io/ObjectStreamClass;.getClassSignature@23[ObjectStreamClass.java:1507],Ljava/io/ObjectStreamField;.<init>@38[ObjectStreamField.java:94],Ljava/io/ObjectStreamField;.<init>@4[ObjectStreamField.java:67]) nframes=6 19: 280 bytes 7 objects 7 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/lang/ref/Reference;.<init>@1[Reference.java:307],Ljava/lang/ref/Reference;.<init>@3[Reference.java:304],Ljava/lang/ref/SoftReference;.<init>@2[SoftReference.java:85],Ljava/lang/Class;.newReflectionData@24[Class.java:2559],Ljava/lang/Class;.reflectionData@45[Class.java:2549]) nframes=6 20: 256 bytes 4 objects 4 live stack=(Ljava/lang/Object;.<init>@1[Object.java:47],Ljava/nio/Buffer;.<init>@1[Buffer.java:197],Ljava/nio/ByteBuffer;.<init>@6[ByteBuffer.java:281],Ljava/nio/ByteBuffer;.<init>@8[ByteBuffer.java:289],Ljava/nio/MappedByteBuffer;.<init>@6[MappedByteBuffer.java:89],Ljava/nio/DirectByteBuffer;.<init>@7[DirectByteBuffer.java:195]) nframes=6 So that, the test must be executed with the correct -classpath option. I qualify this as test run/configuration issue which is a bug not in the product but in the test launch. Closing this issue as "Not an issue".
01-05-2015

This bug looks like a heapTracker demo issue. However, it can be a problem with the execution environment (test run/setup issue).. For instance, the heapTracker demo classes can be not on the classpath. The following comment from the bug description looks suspicious: "Surprisingly, running jdk9-dev-fastdebug with jdk9-dev built demos is fine. Running 8u45 with jdk9-dev built demos triggers the same crash." This gives a clue that there can be something wrong with the location of the built demos. This is the relevant fragment of the cbVMStart callback: cbVMStart(jvmtiEnv *jvmti, JNIEnv *env) { enterCriticalSection(jvmti); { jclass klass; jfieldID field; jint rc; /* Java Native Methods for class */ static JNINativeMethod registry[2] = { {STRING(HEAP_TRACKER_native_newobj), "(Ljava/lang/Object;Ljava/lang/Object;)V", (void*)&HEAP_TRACKER_native_newobj}, {STRING(HEAP_TRACKER_native_newarr), "(Ljava/lang/Object;Ljava/lang/Object;)V", (void*)&HEAP_TRACKER_native_newarr} }; /* Register Natives for class whose methods we use */ klass = (*env)->FindClass(env, STRING(HEAP_TRACKER_class)); if ( klass == NULL ) { fatal_error("ERROR: JNI: Cannot find %s with FindClass\n", STRING(HEAP_TRACKER_class)); } . . . Apparently, it is not a JVMTI error if the HEAP_TRACKER_class was not found.
01-05-2015

The problem once again is trying to throw an exception before the VM has initialized enough to do that. The reproducer indicates that JNI_FindClass is being used and that it should return NULL if the class is not found, but it will also post a NoClassDefFoundError. Hence the crash or assert. What is the difference between 8u45 and 9 initialization sequences? There are a lot of things that are not obviously not allowed during VM startup but which will not work. If the heapTracker demo is failing "out of the box" why was this not found before shipping?
30-04-2015

I agree with Dan, as he is based on the JVMTI spec. Alan suggested to adjust a little bit this part of the JVMTI spec about the phases for Jigsaw to relax it in direction of the module system classes. I'm not very comfortable with this yet and still thinking if there is any other solution.
29-04-2015

This link shows the different JVM/TI Phases: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#jvmtiPhase The VMStart event is sent at the beginning of the "Start Phase" and ends with the VMInit event is sent: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#VMStart http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#VMInit In the "Start Phase", the VM is known to not be completely initialized so the VMStart event handler can and does see the VM in a partially initialized state. The VMStart event handler is restricted in which JVM/TI functions that it can call, but I think all of JNI is available (if there's a JNI force GC call, then that one is probably not available). You can move initialize_java_lang_classes() before the post_vm_start(), but that might result in events being posted before the VMStart event which could confuse agents that don't expect those events before they see the VMStart event. > It looks like post_vm_start() starts the agents running... For an agent that is launched via the command line, it is running long before the VMStart event handler is called. It has to be careful with what it does before that event is received, but it is running. In an earlier comment: > The agents shouldn't be able to have access to the JVM in a partially initialized state. That's not true. Read the VMStart event description.
29-04-2015

As usual, I am ignorant of most of JVMTI. If the initialize_java_lang_classes is called after enter_start_phase before post_vm_start(), would that prevent any events issued by the java lang class static initializer from being invalid because they are issued before the start phase? #4 0x00007ffff4e5fe0d in cbVMStart (jvmti=0x7ffff0004b58, env=0x7ffff000ea30) at agent.cpp:23 #5 0x00007ffff655fc43 in JvmtiExport::post_vm_start () at /scratch/cphillim/hg/jdk9.sean-crash/hotspot/src/share/vm/prims/jvmtiExport.cpp:449 It looks like post_vm_start() starts the agents running and in that case, we don't really want a partially initialized jvm. (?) Do you think we have any tests that would break for this?
29-04-2015

Seems like the change described in the previous note will change the order and JVM/TI phase in which any JVM/TI events issued by the call to initialize_java_lang_classes() occur. Depending on the events, they may no longer be valid if they occur before the JVM/TI StartPhase.
29-04-2015

Moving initializing internally used java classes before agent calls fixes this problem, and seems like the right thing to do. The agents shouldn't be able to have access to the JVM in a partially initialized state. + // Initialize important classes, where we've already created objects, before calling agents. + initialize_java_lang_classes(main_thread, CHECK_JNI_ERR); // Always call even when there are not JVMTI environments yet, since environments // may be attached late and JVMTI must track phases of VM execution JvmtiExport::enter_start_phase(); // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents. JvmtiExport::post_vm_start(); - // Initialize important classes, where we've already created objects, before calling agents. - initialize_java_lang_classes(main_thread, CHECK_JNI_ERR);
29-04-2015

From the look at related failures at the same assert, and also the hs_err, it would seem there is a problem in class initialization sequence, probably "fixed" with the demo code itself in jdk9-dev?
27-04-2015

External user also has a minimal reproducer: https://gist.github.com/Korobochka/dd47fbfb774ffc14a2b5
27-04-2015