United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6834177 Running jsynprog on Solaris Nevada can cause JVM crash
JDK-6834177 : Running jsynprog on Solaris Nevada can cause JVM crash

Details
Type:
Bug
Submit Date:
2009-04-25
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
solaris_nevada
Sub-Component:
compiler
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u14
Fixed Versions:
hs16 (b03)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
Running jsynprog on Solaris Nevada can cause JVM crash.

We use this program in Sun Studio Performance Analyzer testing.
Our tests show this problem on Solaris Nevada SPARC systems (snv_110, snv_111) 
with these java versions:
jdk1.6.0_14-b02 
jdk1.7.0-b48 

We have three Solaris Nevada SPARC systems (2 - snv_110,
1 - snv_111), and the problem happens on all of them, at different
probabilities:

uname -a: SunOS bohr 5.11 snv_110 sun4u sparc sun4u
Sysinfo: SunOS-64-bit, 2 CPUs, sparc 5.11 UltraSPARC I&II
Start date: Wed Apr 22 22:01:22 PDT 2009

I don't see this problem on x64 Solaris 11 systems. Also, it looks
like the problem happens in 64-bit mode only (when 64-bit java is used).

See "Comments" section for details.

                                    

Comments
EVALUATION

The distance for call instruction (call to dtrace_method_entry) in compiled native wraper > 32 bits
since libjvm.so is loaded far from code cache where native wraper is placed:

0xfffffffb84500000    jdk/6_14/ea/b02/binaries/solaris-sparcv9/fastdebug/jre/lib/sparcv9/server/libjvm.so 

Call arguments:

  [7] Assembler::wdisp(0xfffffffbec8085bc, 0x0, 0x1e, 0x108, 0x528, 0x54), at 0xfffffffb6541e74c 
  [8] NativeInstruction::set_wdisp(0x7fda9b4f, 0xfffffffbec8085bc, 0x1e, 0xffffffff7dafe218, 0xffffffff7dafeb78, 0x20), at 0xfffffffb65bcf0a8 
  [9] NativeCall::set_destination(0xffffffff79512d24, 0xfffffffb65d1b2e0, 0xffffffffffffffff, 0x5, 0x0, 0xffffffff7951301d), at 0xfffffffb65bcebf8 
  [10] Relocation::pd_set_call_destination(0xffffffff7dafdb58, 0xfffffffb65d1b2e0, 0xffffffff7dafeb78, 0xffffffff7dafdc80, 0x100139268, 0x100139268), at 0xfffffffb65cf6e58 

  void  set_destination(address dest)       { set_long_at(0, set_wdisp(long_at(0), dest - instruction_address(), call_displacement_width)); }

instruction_address() = 0xffffffff79512d24
dest = 0xfffffffb65d1b2e0

long_at(0) = 0x7fda9b4f
dest - instruction_address() = 0xfffffffbec8085bc  ( -0x4137f7a44 ) does not fit into 32 bits.
call_displacement_width = 0x1e (30)

[t@2 l@2]: x 0xfffffffb65d1b2e0
0xfffffffb65d1b2e0: dtrace_method_entry       :  0x9de3bed0

The NativeFarCall should be used instead of NativeCall.

This is the code in SharedRuntime::generate_native_wrapper() which generates the call:

    __ call_VM_leaf(L7_thread_cache,
         CAST_FROM_FN_PTR(address, SharedRuntime::dtrace_method_entry),
         G2_thread, O1);

The code in MacroAssembler::call() generates call() instead of jumpl_to()
because the wrapper is generated, first, in AdapterHandlerLibrary::_buffer which is
at the same address space as libjvm.so:

[t@1 l@1]: x 0xfffffffb634745a4
0xfffffffb634745a4: __1cVAdapterHandlerLibraryH_buffer_+0x00fc:  0xca70a218

__1cVAdapterHandlerLibraryH_buffer_ == AdapterHandlerLibrary::_buffer
                                     
2009-04-25
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45463a04ca27
                                     
2009-04-30
PUBLIC COMMENTS

Problem:
The code which generates a native call wrapper and a dtrace nmethod
uses VM's static buffer AdapterHandlerLibrary::_buffer for the code
generation before moving it into CodeCache.
During the code generation in the static buffer a runtime call distance
is < 32 bits and the short form of a call instruction is generated.
It may cause problem for 64-bit VM when the relative call distance
to runtime from these methods may not fit into 32-bit if address
distance between CodeCache and VM's code > 32 bits.

Solution:
Use CodeCache buffer blob instead of static buffer AdapterHandlerLibrary::_buffer. 
Also throw an exception in dtrace runtime if nmethod was not generated.
                                     
2009-04-30
EVALUATION

Diffs in

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45463a04ca27
                                     
2009-04-30
EVALUATION

Approved for JDK 7 M3 build 58.
                                     
2009-05-04



Hardware and Software, Engineered to Work Together