United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-7194607 : VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge

Details
Type:
Bug
Submit Date:
2012-08-28
Status:
Resolved
Updated Date:
2014-02-12
Project Name:
JDK
Resolved Date:
2012-11-21
Component:
hotspot
OS:
generic
Sub-Component:
jvmti
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7u60,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Lana's testing of the JDK8-T&L snapshot for JDK8-B54 ran into
a failure in the following test:

java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh

Here is a snippet from the .jtr file:

#section:shell
----------messages:(3/180)----------
command: shell VerifyLocalVariableTableOnRetransformTest.sh []
reason: User specified action: run shell VerifyLocalVariableTableOnRetransformTest.sh 
elapsed time (seconds): 0.813
----------System.out:(43/2795)----------
InstrumentationHandoff JPLIS agent initialized
Reading test class from /Users/aurora/sandbox/gresults/testoutput/jdk_lang/JTwork/classes/java/lang/instrument/DummyClassWithLVT.class
Read 1448 bytes.
Debugging message: Added transformer VerifyLocalVariableTableOnRetransformTest$MyObserver with canRetransform=true
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'DummyClassWithLVT' of 1448 bytes.
Info: DummyClassWithLVT lengths match.
Info: verified 'DummyClassWithLVT.class' matches 'classfileBuffer'.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'DummyClassWithLVT' of 1448 bytes.
Info: DummyClassWithLVT lengths match.
Warning: DummyClassWithLVT[956]: '3' != '1'
Debugging message: tearDown beginning
Exception in thread "main" VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'java/lang/Throwable$WrappedPrintStream' of 699 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'java/lang/Throwable$PrintStreamOrWriter' of 492 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'java/util/IdentityHashMap' of 9068 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'java/util/IdentityHashMap$KeySet' of 1793 bytes.
ATestCaseScaffold$TestCaseScaffoldException: DummyClassWithLVT did not match .class file
	at ATestCaseScaffold.fail(ATestCaseScaffold.java:116)
	at ATestCaseScaffold.assertTrue(ATestCaseScaffold.java:129)
	at VerifyLocalVariableTableOnRetransformTest.verifyClassFileBuffer(VerifyLocalVariableTableOnRetransformTest.java:123)
	at VerifyLocalVariableTableOnRetransformTest.doRunTest(VerifyLocalVariableTableOnRetransformTest.java:72)
	at ATestCaseScaffold.runTest(ATestCaseScaffold.java:60)
	at VerifyLocalVariableTableOnRetransformTest.main(VerifyLocalVariableTableOnRetransformTest.java:66)
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'java/lang/Shutdown' of 2956 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 'java/lang/Shutdown$Lock' of 377 bytes.
ATestCaseScaffold$TestCaseScaffoldException: DummyClassWithLVT did not match .class file
FAIL: found 'did not match .class file' in the test output
INFO: 'javap -v' comparison between the .class files:
1c1
< Classfile /Users/aurora/sandbox/gresults/testoutput/jdk_lang/JTwork/classes/java/lang/instrument/DummyClassWithLVT.class
---
> Classfile /Users/aurora/sandbox/gresults/testoutput/jdk_lang/JTwork/scratch/DummyClassWithLVT.class
3c3
<   MD5 checksum add938cbf65c704016583270092d8258
---
>   MD5 checksum fc840a52f016dcc1e67d00b879bf2ec1
110c110
<       stack=1, locals=1, args_size=1
---
>       stack=3, locals=1, args_size=1
123c123
<       stack=4, locals=11, args_size=1
---
>       stack=6, locals=11, args_size=1
----------System.err:(0/0)----------
result: Failed. Execution failed: exit code 1


test result: Failed. Execution failed: exit code 1
The test was added via the following bug:

    7191322 4/4 add test for 7064927 to java.lang.instrument

as a way to test the following bug fix:

    7064927 4/4 retransformClasses() does not pass in LocalVariableTable
                of a method

The test was pushed to T&L for the JDK8-B54 snapshot so
the test is new relative to the merge with the JSR-292
changes that landed in JDK8-B52 and JDK8-B54.

                                    

Comments
7u60-critical-request justification:

This bug fix is better to be in the release because it is a part of the JSR-292 support
in the JVMTI HotSwap API (includes RedefineClasses, RetransformClasses and PopFrame).

This bug is one of 12 bug fixes that depend on each other and must be integrated
in the order:
  https://jbs.oracle.com/bugs/browse/JDK-7194607
  https://jbs.oracle.com/bugs/browse/JDK-8005128
  https://jbs.oracle.com/bugs/browse/JDK-8006542
  https://jbs.oracle.com/bugs/browse/JDK-8006546
  https://jbs.oracle.com/bugs/browse/JDK-8006731
  https://jbs.oracle.com/bugs/browse/JDK-8008511
  https://jbs.oracle.com/bugs/browse/JDK-8007037
  https://jbs.oracle.com/bugs/browse/JDK-8014288
  https://jbs.oracle.com/bugs/browse/JDK-8013945
  https://jbs.oracle.com/bugs/browse/JDK-8014052
  https://jbs.oracle.com/bugs/browse/JDK-7187554
  https://jbs.oracle.com/bugs/browse/JDK-8023004

All the fixes above have been already integrated into the JDK 8
and tested in the hotspot-rt nightly for several months.

Risk: low
  The fixes touch the JVMTI HotSwap API that includes RedefineClasses, RetransformClasses and PopFrame.
  The risk is only to introduce regressions in this part of the JVMTI implementation.
  This impacts only the debugging and profiling tools that use the JVMTI HotSwap feature.
  There are very small chances for regressions to sneak into the class file
  constant pool processing and method handles implementation.

Webrevs and reviewers:
  The 7u60 webrevs location is:
    http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/7u_port/

  The fixes above were already passed the review process before integration
  into JDK 8. The reviewers were: twisti, jrose, coleenp, dholmes, etc.
  The 7u60 edition of fixes must be reviewed at least by jrose and twisti.

Level of effort:
  All fixes need a secondary review phase after rebase from jdk8 to 7u60 repository.

Testing coverage:
  The folllowing test suites must be run to ensure correctness of the fixes:
    JTREG tests: com/sun/jdi, java/lang/instrument
    NSK tests: vm.mlvm.testlist, nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist

Result of not integrating:
  The users will not be able to use HotSwap technology for debuging and profiling
  Java code that depends on the JSR-292 implementation.
  In that case the integration of these fixes will have to be requested/escalated
  in 7 updates by the tool vendors and/or customers.
                                     
2014-01-10
URL:   http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/64812523d72e
User:  amurillo
Date:  2012-11-21 19:11:18 +0000

                                     
2012-11-21
Changed priority to P3 as it is a regression.
This is a hotspot/jvmti bug caused by changes in oops/method.hpp for invokedynamic (JSR 292).
Now the max_stack() adds 2 to the original code attribute stack size if invokedynamic is enabled.
The verifier_max_stack() must be used in the jvmtiClassFileReconstituter.cpp instead of the max_size() to get the code attribute stack size.
                                     
2012-10-30
With the fix above the test is passed.
                                     
2012-10-30
I believe the following change will fix the issue:

diff -r 0cc77f9b31ad src/share/vm/prims/jvmtiClassFileReconstituter.cpp
--- a/src/share/vm/prims/jvmtiClassFileReconstituter.cpp        Thu Oct 11 09:49:18 2012 -0700
+++ b/src/share/vm/prims/jvmtiClassFileReconstituter.cpp        Tue Oct 30 03:13:27 2012 -0700
@@ -228,7 +228,7 @@
 
   write_attribute_name_index("Code");
   write_u4(size);
-  write_u2(method->max_stack());
+  write_u2(method->verifier_max_stack());
   write_u2(method->max_locals());
   write_u4(code_size);
   copy_bytecodes(method, (unsigned char*)writeable_address(code_size));
                                     
2012-10-30



Hardware and Software, Engineered to Work Together