JDK-7182152 : Instrumentation hot swap test incorrect monitor count
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 7u4
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2012-07-06
  • Updated: 2014-11-19
  • Resolved: 2013-02-06
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 7 JDK 8 Other
7u21Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
JDK-8007420 - add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument
Relates :  
JDK-6805864 - Problem with jvmti->redefineClasses: some methods don't get redefined
Description
SHORT SUMMARY:
WLS Testing shows problems when using redefine methods to do hotswapping of 
classes. They are working on a standalone reproducer, but still don't have 
any. Also, I am not sure if this is a JVM issue, but they would need help at 
least with diagnostic flags to help them move forward

From one of their engineers: "This issue is important for us to fix in 
12.1.2, since WLDF hotswap feature is broken with HotSpot."
This will not make 7u10 since we have not yet found a way to duplicate it or to collect sufficient information from the customer.
Comments
Add Code Review Round 0 and Code Review Round 1 webrevs for HSX-23.6, HSX-24 and HSX-25 versions. Add Code Review Round 2 webrev for HSX-25 version.
11-02-2013
Raj used a test build to verify that the new tracing code catches the WLS failure mode earlier; it is now caught at the end of class redefinition instead of when the obsolete method is executed. Raj also verified that the 1-liner fix appears to solve the issue in the WLS test environment.
31-01-2013
Looks like I wrote a test for 6805864 called RedefineAbstractClass.sh, but it also looks like I forgot to push the test to the JDK repo (where JLI/JPLIS tests live). I ran the JPDA stack of tests over the weekend on Win32 and Solaris X86 using the new sanity checking code. Looks like the following existing JLI/JPLIS test triggers the new sanity check code: test name: java/lang/instrument/IsModifiableClassAgent.java log file: sdk-jli-prod-server_7182152_exp_dcubed-fast-mixed.windows-i586/JTwork/java/lang/instrument/IsModifiableClassAgent.jtr This is an UNEXPECTED test FAILure. on allbugs list via: 6889484 6994630 7187046 The IsModifiableClassAgent test retransforms all classes that are "modifiable" and that finds "old" method references in a class's itable: RedefineClasses-0x4000: calling check_class RedefineClasses-0x4000: klassItable::check_no_old_or_obsolete_entries failure -- OLD method found -- class: Ljava/util/Collections$UnmodifiableRandomAccessList; itable dump -- ( 0) public -- virtual jobject java.util.Collections$UnmodifiableCollection.iterator() ( 1) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.add(jobject) ( 2) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.remove(jobject) ( 3) public -- virtual jboolean java.util.Collections$UnmodifiableList.equals(jobject) ( 4) public -- virtual jint java.util.Collections$UnmodifiableList.hashCode() ( 5) public -- virtual void java.util.Collections$UnmodifiableCollection.clear() ( 6) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.contains(jobject) ( 7) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.isEmpty() ( 8) public -- virtual jint java.util.Collections$UnmodifiableCollection.size() ( 9) public -- virtual jobject java.util.Collections$UnmodifiableCollection.toArray() ( 10) public -- virtual jobject java.util.Collections$UnmodifiableCollection.toArray(jobject) ( 11) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.addAll(jobject) ( 12) public {old} -- virtual jobject java.util.Collections$UnmodifiableCollection.iterator() ( 13) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.containsAll(jobject) ( 14) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.removeAll(jobject) ( 15) public -- virtual jboolean java.util.Collections$UnmodifiableCollection.retainAll(jobject) ( 16) public {old} -- virtual jboolean java.util.Collections$UnmodifiableCollection.add(jobject) <snip> # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=\\jvmtiRedefineClasses.cpp:3425 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (c:\\work\\shared\\bug_hunt\\WLS_RedefineClasses\\src\\7182152_exp\\src\\share\\vm\\prims\\jvmtiRedefineClasses.cpp:3425), pid=8768, tid=11056 # guarantee(false) failed: OLD and/or OBSOLETE method(s) found # # JRE version: 7.0_10-b18 # Java VM: Java HotSpot(TM) Client VM (23.6-b04-7182152_exp_dcubed-fastdebug mixed mode windows-x86 ) # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\\work\\local\\test_results\\jdk7u10\\exp\\7182152.0\\sdk-jli-prod-client_7182152_exp_dcubed-fast-mixed.windows-i586\\JTwork\\java\\lang\\instrument\\IsModifiableClassAgent\\hs_err_pid8768.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp #
28-01-2013
Here's the changeset that put the "break" back: $ hg log -r 661 -v src/share/vm/oops/klassVtable.cpp changeset: 661:4aaa9f5e02a8 user: acorn date: Wed Mar 18 17:20:57 2009 -0400 files: src/share/vm/classfile/classFileParser.cpp src/share/vm/oops/instanceKlass.cpp src/share/vm/oops/instanceKlass.hpp src/share/vm/oops/klassVtable.cpp src/share/vm/oops/klassVtable.hpp description: 4766230: Hotspot vtable inconsistencies cause core dumps. 6579515. 6582242. Reviewed-by: kamg, coleenp There are a lot of diffs to src/share/vm/oops/klassVtable.cpp in that changeset. Here is the relevant (and last) diff: $ hg diff -r 660 -r 661 src/share/vm/oops/klassVtable.cpp diff -r 8ce995316d10 -r 4aaa9f5e02a8 src/share/vm/oops/klassVtable.cpp --- a/src/share/vm/oops/klassVtable.cpp Mon Mar 16 08:50:53 2009 -0400 +++ b/src/share/vm/oops/klassVtable.cpp Wed Mar 18 17:20:57 2009 -0400 <snip> @@ -1012,6 +1006,7 @@ void klassItable::adjust_method_entries( new_method->name()->as_C_string(), new_method->signature()->as_C_string())); } + break; } ime++; }
26-01-2013
Here's the changeset that added the comment and removed the "break": $ hg log -r 606 -v src/share/vm/oops/klassVtable.cpp changeset: 606:70998f2e05ef user: dcubed date: Mon Mar 02 14:03:03 2009 -0700 files: src/cpu/sparc/vm/interp_masm_sparc.cpp src/cpu/sparc/vm/sharedRuntime_sparc.cpp src/cpu/x86/vm/interp_masm_x86_32.cpp src/cpu/x86/vm/interp_masm_x86_64.cpp src/cpu/x86/vm/sharedRuntime_x86_32.cpp src/cpu/x86/vm/sharedRuntime_x86_64.cpp src/share/vm/includeDB_core src/share/vm/oops/klassVtable.cpp src/share/vm/prims/jvmtiRedefineClassesTrace.hpp src/share/vm/runtime/sharedRuntime.cpp src/share/vm/runtime/sharedRuntime.hpp description: 6805864: 4/3 Problem with jvmti->redefineClasses: some methods don't get redefined Summary: Remove incorrect optimization in klassItable::adjust_method_entries(). Add RedefineClasses() tracing support for obsolete method entry. Reviewed-by: acorn, swamyv Here's the diffs to src/share/vm/oops/klassVtable.cpp from that changeset: $ hg diff -r 605 -r 606 src/share/vm/oops/klassVtable.cpp diff -r ea20d7ce26b0 -r 70998f2e05ef src/share/vm/oops/klassVtable.cpp --- a/src/share/vm/oops/klassVtable.cpp Mon Mar 02 14:00:23 2009 -0700 +++ b/src/share/vm/oops/klassVtable.cpp Mon Mar 02 14:03:03 2009 -0700 @@ -992,6 +992,10 @@ void klassItable::adjust_method_entries( methodOop new_method = new_methods[j]; itableMethodEntry* ime = method_entry(0); + // The itable can describe more than one interface and the same + // method signature can be specified by more than one interface. + // This means we have to do an exhaustive search to find all the + // old_method references. for (int i = 0; i < _size_method_table; i++) { if (ime->method() == old_method) { ime->initialize(new_method); @@ -1008,7 +1012,6 @@ void klassItable::adjust_method_entries( new_method->name()->as_C_string(), new_method->signature()->as_C_string())); } - break; } ime++; } So we fixed this bug before back in 2009.
26-01-2013
The new test is partly based on a snippet of code that I saw in one of four files changed by the Perm Gen Removal (PGR) project that Coleen sent my way as possibly relevant to this bug. Here is the code: src/share/vm/oops/klassVtable.cpp (8ce625481709 in HSX-23.6) 969 void klassItable::adjust_method_entries(methodOop* old_methods, methodOo p* new_methods, 970 int methods_length, bool * trace _name_printed) { 971 // search the itable for uses of either obsolete or EMCP methods 972 for (int j = 0; j < methods_length; j++) { 973 methodOop old_method = old_methods[j]; 974 methodOop new_method = new_methods[j]; 975 itableMethodEntry* ime = method_entry(0); 976 977 // The itable can describe more than one interface and the same 978 // method signature can be specified by more than one interface. 979 // This means we have to do an exhaustive search to find all the 980 // old_method references. 981 for (int i = 0; i < _size_method_table; i++) { 982 if (ime->method() == old_method) { 983 ime->initialize(new_method); 984 985 if (RC_TRACE_IN_RANGE(0x00100000, 0x00400000)) { 986 if (!(*trace_name_printed)) { 987 // RC_TRACE_MESG macro has an embedded ResourceMark 988 RC_TRACE_MESG(("adjust: name=%s", 989 Klass::cast(old_method->method_holder())->external_name()) ); 990 *trace_name_printed = true; 991 } 992 // RC_TRACE macro has an embedded ResourceMark 993 RC_TRACE(0x00200000, ("itable method update: %s(%s)", 994 new_method->name()->as_C_string(), 995 new_method->signature()->as_C_string())); 996 } 997 break; 998 } 999 ime++; 1000 } 1001 } 1002 } The interesting part is that the comment on lines 977-980 do not match the code on line 997. More research needed.
26-01-2013
New sanity checking code running on JDK7u10-HSX-23.6 product bits with a new test: ----------System.out:(60/3480)*---------- INFO: building the replacement classes. INFO: launching RedefineSubclassWithTwoInterfacesApp Hello from RedefineSubclassWithTwoInterfacesAgent! isRedefineClassesSupported()=true java version "1.7.0_10" Java(TM) SE Runtime Environment (build 1.7.0_10-b18) Java HotSpot(TM) Client VM (build 23.6-b04-7182152_exp_dcubed-product, mixed mode) Hello from RedefineSubclassWithTwoInterfacesApp! RedefineSubclassWithTwoInterfacesApp: mesg='intf1<echo: (version-0) <test message #0>> intf2< echo: (version-0) <test message #0>>' before any redefines Reading test class from RedefineSubclassWithTwoInterfacesImpl_1.class RedefineClasses-0x1: loading name=RedefineSubclassWithTwoInterfacesImpl kind=102 (avail_mem=1284424K) RedefineClasses-0x1: loaded name=RedefineSubclassWithTwoInterfacesImpl (avail_mem=1284400K) RedefineClasses: adjust: name=RedefineSubclassWithTwoInterfacesImpl RedefineClasses-0x1: redefined name=RedefineSubclassWithTwoInterfacesImpl, count=1 (avail_mem=1284372K) RedefineClasses-0x4000: calling check_class RedefineClasses-0x4: vm_op: all=0 prologue=0 doit=0 RedefineClasses-0x4: redefine_single_class: phase1=0 phase2=0 Reading test class from RedefineSubclassWithTwoInterfacesTarget_1.class RedefineClasses-0x1: loading name=RedefineSubclassWithTwoInterfacesTarget kind=102 (avail_mem=1283092K) RedefineClasses-0x1: loaded name=RedefineSubclassWithTwoInterfacesTarget (avail_mem=1283092K) RedefineClasses: adjust: name=RedefineSubclassWithTwoInterfacesTarget RedefineClasses-0x100000: vtable method update: echo((Ljava/lang/String;)Ljava/lang/String;) RedefineClasses-0x200000: itable method update: echo((Ljava/lang/String;)Ljava/lang/String;) RedefineClasses-0x1: redefined name=RedefineSubclassWithTwoInterfacesTarget, count=1 (avail_mem=1282828K) RedefineClasses-0x4000: calling check_class RedefineClasses-0x4000: klassItable::check_no_old_or_obsolete_entries failure -- OLD method found -- class: LRedefineSubclassWithTwoInterfacesImpl; itable dump -- ( 0) -- ( 1) -- RedefineClasses-0x4000: _old_methods -- RedefineClasses-0x4000: 0 ( -2) -- RedefineClasses-0x4000: 1 ( 5) -- RedefineClasses-0x4000: _new_methods -- RedefineClasses-0x4000: 0 ( -2) -- RedefineClasses-0x4000: 1 ( 5) -- RedefineClasses-0x4000: _matching_(old/new)_methods -- RedefineClasses-0x4000: 0 ( -2) -- RedefineClasses-0x4000: ( -2) RedefineClasses-0x4000: 1 ( 5) -- RedefineClasses-0x4000: ( 5) RedefineClasses-0x4000: _deleted_methods -- RedefineClasses-0x4000: _added_methods -- # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (jvmtiRedefineClasses.cpp:3425), pid=4376, tid=3640 # guarantee(false) failed: OLD and/or OBSOLETE method(s) found # # JRE version: 7.0_10-b18 # Java VM: Java HotSpot(TM) Client VM (23.6-b04-7182152_exp_dcubed-product mixed mode windows-x86 ) # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\\work\\shared\\bug_hunt\\jdk8\\exp\\test\\java\\lang\\instrument\\sdk-jli.windows-i586\\JTwork\\java\\lang\\instrument\\RedefineSubclassWithTwoInterfaces\\hs_err_pid4376.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # FAIL: RedefineSubclassWithTwoInterfacesApp failed. ----------System.err:(0/0)---------- result: Failed. Execution failed: exit code 1 The product bits catch a stale itable reference to a redefine method. Don't know if this is the WLS bug or not, but it is promising. The product debug output is not great since some pieces are "empty" in product bits. Here's the same failure with fastdebug bits: ----------System.out:(62/4381)*---------- INFO: building the replacement classes. INFO: launching RedefineSubclassWithTwoInterfacesApp Hello from RedefineSubclassWithTwoInterfacesAgent! isRedefineClassesSupported()=true java version "1.7.0_10" Java(TM) SE Runtime Environment (build 1.7.0_10-b18) Java HotSpot(TM) Client VM (build 23.6-b04-7182152_exp_dcubed-fastdebug, mixed mode) Hello from RedefineSubclassWithTwoInterfacesApp! RedefineSubclassWithTwoInterfacesApp: mesg='intf1<echo: (version-0) <test message #0>> intf2< echo: (version-0) <test message #0>>' before any redefines Reading test class from RedefineSubclassWithTwoInterfacesImpl_1.class RedefineClasses-0x1: loading name=RedefineSubclassWithTwoInterfacesImpl kind=102 (avail_mem=1244440K) RedefineClasses-0x1: loaded name=RedefineSubclassWithTwoInterfacesImpl (avail_mem=1244416K) RedefineClasses: adjust: name=RedefineSubclassWithTwoInterfacesImpl RedefineClasses-0x1: redefined name=RedefineSubclassWithTwoInterfacesImpl, count=1 (avail_mem=1244376K) RedefineClasses-0x4000: calling check_class RedefineClasses-0x4: vm_op: all=4 prologue=4 doit=0 RedefineClasses-0x4: redefine_single_class: phase1=0 phase2=0 Reading test class from RedefineSubclassWithTwoInterfacesTarget_1.class RedefineClasses-0x1: loading name=RedefineSubclassWithTwoInterfacesTarget kind=102 (avail_mem=1244308K) RedefineClasses-0x1: loaded name=RedefineSubclassWithTwoInterfacesTarget (avail_mem=1244304K) RedefineClasses: adjust: name=RedefineSubclassWithTwoInterfacesTarget RedefineClasses-0x100000: vtable method update: echo((Ljava/lang/String;)Ljava/lang/String;) RedefineClasses-0x200000: itable method update: echo((Ljava/lang/String;)Ljava/lang/String;) RedefineClasses-0x1: redefined name=RedefineSubclassWithTwoInterfacesTarget, count=1 (avail_mem=1244296K) RedefineClasses-0x4000: calling check_class RedefineClasses-0x4000: klassItable::check_no_old_or_obsolete_entries failure -- OLD method found -- class: LRedefineSubclassWithTwoInterfacesImpl; itable dump -- ( 0) public -- virtual jobject RedefineSubclassWithTwoInterfacesTarget.echo(jobject) ( 1) public {old} {obsolete} -- virtual jobject RedefineSubclassWithTwoInterfacesTarget.echo(jobject) RedefineClasses-0x4000: _old_methods -- RedefineClasses-0x4000: 0 ( -2) public {old} -- virtual void RedefineSubclassWithTwoInterfacesTarget.<init>() RedefineClasses-0x4000: 1 ( 5) public {old} {obsolete} -- virtual jobject RedefineSubclassWithTwoInterfacesTarget.echo(jobject) RedefineClasses-0x4000: _new_methods -- RedefineClasses-0x4000: 0 ( -2) public -- virtual void RedefineSubclassWithTwoInterfacesTarget.<init>() RedefineClasses-0x4000: 1 ( 5) public -- virtual jobject RedefineSubclassWithTwoInterfacesTarget.echo(jobject) RedefineClasses-0x4000: _matching_(old/new)_methods -- RedefineClasses-0x4000: 0 ( -2) public {old} -- virtual void RedefineSubclassWithTwoInterfacesTarget.<init>() RedefineClasses-0x4000: ( -2) public RedefineClasses-0x4000: 1 ( 5) public {old} {obsolete} -- virtual jobject RedefineSubclassWithTwoInterfacesTarget.echo(jobject) RedefineClasses-0x4000: ( 5) public RedefineClasses-0x4000: _deleted_methods -- RedefineClasses-0x4000: _added_methods -- # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=\\jvmtiRedefineClasses.cpp:3425 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (c:\\work\\shared\\bug_hunt\\WLS_RedefineClasses\\src\\7182152_exp\\src\\share\\vm\\prims\\jvmtiRedefineClasses.cpp:3425), pid=5832, tid=4744 # guarantee(false) failed: OLD and/or OBSOLETE method(s) found # # JRE version: 7.0_10-b18 # Java VM: Java HotSpot(TM) Client VM (23.6-b04-7182152_exp_dcubed-fastdebug mixed mode windows-x86 ) # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\\work\\shared\\bug_hunt\\jdk8\\exp\\test\\java\\lang\\instrument\\sdk-jli.windows-i586\\JTwork\\java\\lang\\instrument\\RedefineSubclassWithTwoInterfaces\\hs_err_pid5832.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # FAIL: RedefineSubclassWithTwoInterfacesApp failed. ----------System.err:(0/0)---------- result: Failed. Execution failed: exit code 1 test result: Failed. Execution failed: exit code 1
26-01-2013
In the HSX-12 code base, there is some interesting sanity checking code: src/share/vm/oops/klassVtable.cpp:bool klassVtable::check_no_old_entries() { src/share/vm/oops/klassVtable.hpp: bool check_no_old_entries(); src/share/vm/prims/jvmtiRedefineClasses.cpp: if (!ik->vtable()->check_no_old_entries()) { src/share/vm/prims/jvmtiRedefineClasses.cpp: tty->print_cr("klassVtable::check_no_old_entries failure -- OLD method found -- class: %s", ik->signature_name()); The klassVtable::check_no_old_entries() stuff was added by the following old delta: src/share/vm/oops/SCCS/s.klassVtable.cpp: D 1.135 06/04/21 12:28:46 rfield 293 292 00055/00042/01200 MRs: COMMENTS: 6404550: missing late attach (JVM TI redefine) functionality Permit the adding or deleting of private methods with redefine In the HSX-25 code base, there is even more interesting code: src/share/vm/prims/jvmtiRedefineClasses.cpp: if (!ik->vtable()->check_no_old_entries()) { src/share/vm/prims/jvmtiRedefineClasses.cpp: tty->print_cr("klassVtable::check_no_old_entries failure -- OLD method found -- class: %s", ik->signature_name()); src/share/vm/prims/jvmtiRedefineClasses.cpp: if (!ik->itable()->check_no_old_entries()) { src/share/vm/prims/jvmtiRedefineClasses.cpp: tty->print_cr("klassItable::check_no_old_entries failure -- OLD method found -- class: %s", ik->signature_name()); src/share/vm/prims/jvmtiRedefineClasses.cpp: !ik->constants()->cache()->check_no_old_entries()) { src/share/vm/prims/jvmtiRedefineClasses.cpp: tty->print_cr("klassVtable::check_no_old_entries failure -- OLD method found -- class: %s", ik->signature_name()); src/share/vm/oops/cpCache.cpp:bool ConstantPoolCacheEntry::check_no_old_entries() { src/share/vm/oops/cpCache.cpp:bool ConstantPoolCache::check_no_old_entries() { src/share/vm/oops/cpCache.cpp: !entry_at(i)->check_no_old_entries()) { src/share/vm/oops/cpCache.hpp: NOT_PRODUCT(bool check_no_old_entries();) src/share/vm/oops/cpCache.hpp: NOT_PRODUCT(bool check_no_old_entries();) src/share/vm/oops/klassVtable.cpp:bool klassVtable::check_no_old_entries() { src/share/vm/oops/klassVtable.cpp:bool klassItable::check_no_old_entries() { src/share/vm/oops/klassVtable.hpp: bool check_no_old_entries(); src/share/vm/oops/klassVtable.hpp: bool check_no_old_entries(); The new sanity checking code was added by the following changeset: changeset: 3601:da91efe96a93 parent: 3598:36d1d483d5d6 user: coleenp date: Sat Sep 01 13:25:18 2012 -0400 summary: 6964458: Reimplement class meta-data storage to use native memory Many thanks to Coleen for pointing me at the new sanity checking code. I'm porting to my 7u10/HSX23.6 environment.
24-01-2013
Forgot to log additional testing info from Raj: On 12/7/12 4:21 PM, Rajendra Inamdar wrote: > I tried it with: > > java.runtime.version = 1.7.0_10-ea-b16 > java.runtime.version = 1.8.0-ea-b01 > java.runtime.version = 1.8.0-ea-b51 > java.runtime.version = 1.8.0-ea-b57 > java.runtime.version = 1.8.0-ea-b58 > > It failed with all except 1.8.0-ea-b58. > > /Raj
24-01-2013
Current facts: - reproduces on JDK1.6.0_27-B06/HSX-20.2-B06 - reproduces on JDK1.7.0_04-B20/HSX-23.0-B21 - reproduces on JDK1.7.0_07-B10/HSX-23.3-B01 - reproduces using '-client' and '-d64 -server' - class redefinitions are done 1 at a time - class is redefined to "original" bits, but a transformer can update the bits to the latest instrumentation config Current observations: - reproduces on Linux x86_64 running as a virtualized machine; other OSes not tested so far - reproduces using 64-bit Server VM; also reproduces with -client, -server and -Xint; not clear whether 32-bit -server was tested, not clear which VM was used with -Xint - reproduces in the Web Logic Server (WLS) environment - reproduces when redefinition/transformation happens in the following order: A) wlstest.unit.diagnostics.common.apps.echoejb.EchoBean4_nh7k_Impl B) wlstest.unit.diagnostics.common.apps.echoejb.EchoBean4 Other classes may have been redefined between "A" and "B" and after "B" - does not reproduce when redefinition/transformation happens in the following order: M) wlstest.unit.diagnostics.common.apps.echoejb.EchoBean4 N) wlstest.unit.diagnostics.common.apps.echoejb.EchoBean4_nh7k_Impl Other classes may have been redefined between "M" and "N" and after "N" - EchoBean4_nh7k_Impl is a container generated class, which extends EchoBean4: public class EchoBean4_nh7k_Impl extends EchoBean4 - stack shows that wlstest.unit.diagnostics.common.apps.echoejb.EchoBean4_nh7k_EchoRemoteImpl.__WL_invoke(Ljava/lang/Object;[Ljava/lang/Object;I)Ljava/lang/Object;+30 calls the obsolete wlstest.unit.diagnostics.common.apps.echoejb.EchoBean4.echo(Ljava/lang/String;)Ljava/lang/String;+0
29-11-2012