JDK-7124706 : enable RetransformBigClass.sh test when fix for 8013063 is promoted
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.instrument
  • Affected Version: 7u4,8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-12-23
  • Updated: 2013-06-28
  • Resolved: 2013-06-08
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
8 b96Fixed
Related Reports
Relates :  
JDK-8013063 - nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free
Relates :  
JDK-7121600 - Instrumentation.redefineClasses() leaks class bytes
Relates :  
JDK-7122253 - Instrumentation.retransformClasses() leaks class bytes
Description
The test for the following bug:

    7122253 2/3 Instrumentation.retransformClasses() leaks class bytes

lives in the JDK repo because that is where the java.lang.instrument
(JLI/JPLIS) tests are located. The RetransformBigClass.sh test was
pushed using related bug 7121600, but it was pushed with an "@ignore"
tag.

The fix for 7122253 is in the hotspot repo and when that fix is
available in a promoted build, then the following test can be
enabled:

    java/lang/instrument/RetransformBigClass.sh

The test can be enabled by removing the "@ignore" line.
Comments
Was 7122253.
07-05-2013
This is why I couldn't find it - I thought MakeJAR4.sh was used by lots of these tests so couldn't possibly be broken. Thanks!
07-05-2013
With this patch the test ran fine for me.
07-05-2013
Try the patch below. Apparently when TESTTOOLVMOPTS was added we didn't see the error since the test wasn't being run. diff --git a/test/java/lang/instrument/MakeJAR4.sh b/test/java/lang/instrument/MakeJAR4.sh --- a/test/java/lang/instrument/MakeJAR4.sh +++ b/test/java/lang/instrument/MakeJAR4.sh @@ -43,4 +43,4 @@ done -${JAR} "{TESTTOOLVMOPTS}" cvfm ${AGENT}.jar ${AGENT}.mf ${AGENT}*.class ${OTHER}*.java +${JAR} ${TESTTOOLVMOPTS} cvfm ${AGENT}.jar ${AGENT}.mf ${AGENT}*.class ${OTHER}*.java
07-05-2013
I don't understand how these tests run. If I comment out @ignore, I get: Illegal option: { Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C dir] files ... Options: -c create new archive -t list table of contents for archive -x extract named (or all) files from archive -u update existing archive -v generate verbose output on standard output -f specify archive file name -m include manifest information from specified manifest file -e specify application entry point for stand-alone application bundled into an executable jar file -p specify profile name -0 store only; use no ZIP compression -M do not create a manifest file for the entries -i generate index information for the specified jar files -C change to the specified directory and include the following file If any file is a directory then it is processed recursively. The manifest file name, the archive file name and the entry point name are specified in the same order as the 'm', 'f' and 'e' flags. Example 1: to archive two class files into an archive called classes.jar: jar cvf classes.jar Foo.class Bar.class Example 2: use an existing manifest file 'mymanifest' and archive all the files in the foo/ directory into 'classes.jar': jar cvfm classes.jar mymanifest -C foo/ . result: Failed. Execution failed: exit code 1
06-05-2013
Did this test pass once? The fix for the memory leak has been promoted but now It gets crash: Stack: [0x8f609000,0x8f65a000], sp=0x8f658238, free space=316k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x110020] getaliasbyname_r+0x3f80 C [libinstrument.so+0x5586] transformClassFile+0x156 C [libinstrument.so+0x1bb8] eventHandlerClassFileLoadHook+0x88 V [libjvm.so+0x8a37ff] JvmtiExport::post_class_file_load_hook(Symbol*, Handle, H andle, unsigned char**, unsigned char**, unsigned char**, int*)+0x27f V [libjvm.so+0x4bb82e] ClassFileParser::parseClassFile(Symbol*, ClassLoaderData* , Handle, KlassHandle, GrowableArray<Handle>*, TempNewSymbol&, bool, Thread*)+0x26 e V [libjvm.so+0xb8cc42] SystemDictionary::parse_stream(Symbol*, Handle, Handle, C lassFileStream*, KlassHandle, GrowableArray<Handle>*, Thread*)+0xe2 V [libjvm.so+0x8be394] VM_RedefineClasses::load_new_class_versions(Thread*)+0x35 4 V [libjvm.so+0x8bf12f] VM_RedefineClasses::doit_prologue()+0xaf V [libjvm.so+0xc6394f] VMThread::execute(VM_Operation*)+0x6f V [libjvm.so+0x886ce1] JvmtiEnv::RetransformClasses(int, _jclass* const*)+0x281 V [libjvm.so+0x83d00f] jvmti_RetransformClasses+0x14f C [libinstrument.so+0x44ef] retransformClasses+0x22f C [libinstrument.so+0x1a5b] Java_sun_instrument_InstrumentationImpl_retransformC
05-12-2012