United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-5009610 64 bit JVM cores with target address not reachable with call instruction
JDK-5009610 : 64 bit JVM cores with target address not reachable with call instruction

Details
Type:
Bug
Submit Date:
2004-03-08
Status:
Closed
Updated Date:
2004-04-28
Project Name:
JDK
Resolved Date:
2004-03-23
Component:
hotspot
OS:
solaris_8
Sub-Component:
runtime
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
1.4.2_05 (05)

Related Reports
Backport:

Sub Tasks

Description
have simulated most of this behavior (minus the socket listening)
inside the attached file "invoke3.cc". The objective is to have the
Server talk to a Java application. The way we plan of doing this is to
use the JNI Invocation API and create a JVM from inside the C++ code.
he exact place where this JVM is created (i.e., either before the
memory-mapping step -2-, or after it and before the fork step -4-, or
inside the child process and before the thread creation step -5-, or
after the threads are created) is up to us. We look for the most
efficient and flexible solution.
 
The problem we face is that when we try to create the JVM in the parent
process after the memory-mapping and before the fork, we get signal 11> errors because apparently there is not enough memory for the JVM to
start. If I reduce the size of the memory-mapped file to less than 1 GB
everything works fine and the JVM is created successfully. I have tried
to use the "-Xmx" flag inside the C++ code to reduce the size of the JVM
heap but it did not work. My current environment has about 48 GB of memory.

Attached is said test case:
the Makefile is currently set to my machine with the latest java_g build of 1.5.0 (java_g is used by using jvm_g LIB arg in the makefile)
This also cores with 1.4.2 and 1.4.1
You'll most likely want to change this and then run make again.

Looks initially similar to bugs 4467771 and 4475282, but with this particular problem it appears the VM doesn't appear to start or at least has problems and these bugs are showing fixed in merlin....

You can change VM args in the actual invoke3.cc code.

run make

to run the test case
invoke3 50000
There is a cutoff for the number for the argument in the startup.
48609 for the regular non debug JDK. below that will allow the JVM to start
and the test case to finish.

It will core almost immediately otherwise.  depending how close you get to 48609 it will be earlier in the running or later.

I originally thought that this was a JNI issue as running with the non debug jvm and the flag -XX:ShowMessageBoxOnError it simply cored and the flag did not trap any jvm failure, but with the debug jvm (java_g) the flag caught the failure and the subsequent stack and error message was given:

(this was with 1.5.0 beta 2)

(dbx) where
current thread: t@1
  [1] _read(0x0, 0xffffffff7fffdd80, 0x10, 0x2f, 0x0, 0xff00), at 0xffffffff7cea67e0 
  [2] _ti_read(0x0, 0xffffffff7fffdd80, 0x10, 0xffffffff7fffde78, 0x1a8, 0xf51b), at 0xffffffff7f3108a4 
  [3] os::message_box(0xffffffff7ebf1c07, 0xffffffff7eea5780, 0xffffffff7ebf1b4a, 0xf51b, 0x1, 0xff00), at 0xffffffff7e5c9f0c 
  [4] VMError::show_message_box(0xffffffff7fffe140, 0xffffffff7eea5780, 0x7d0, 0x0, 0x0, 0x0), at 0xffffffff7e91e230 
  [5] VMError::report_and_die(0xffffffff7fffe140, 0x100150d58, 0xffffffff7e9ac6f1, 0xffffffff7e9ac6a7, 0x1a8, 0x0), at 0xffffffff7e91bda8 
  [6] report_assertion_failure(0xffffffff7e9ac6a7, 0x1a8, 0xffffffff7e9ac6f1, 0x0, 0x0, 0x0), at 0xffffffff7df40de4 
  [7] MacroAssembler::call(0x100151438, 0xffffffff7dc8ff08, 0x6, 0x0, 0xffffffff7fffe300, 0xffffffff7fffe45c), at 0xffffffff7dca064c 
  [8] MacroAssembler::get_thread(0x100151438, 0xffffffff7fffe45c, 0x0, 0x1, 0xffffffff7fffe45c, 0x0), at 0xffffffff7dc90120 
  [9] StubGenerator::generate_forward_exception(0xffffffff7fffe7c0, 0x100151338, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7e7bff28 
  [10] StubGenerator::generate_initial(0xffffffff7fffe7c0, 0x100151338, 0x4e70, 0x0, 0x0, 0x0), at 0xffffffff7e7bac28 
  [11] StubGenerator::StubGenerator(0xffffffff7fffe7c0, 0x100151338, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7e7b9ee8 
  [12] StubGenerator_generate(0x100151338, 0x0, 0x4e20, 0x1, 0x0, 0x0), at 0xffffffff7e7b9b3c 
  [13] StubRoutines::initialize1(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7e7cb840 
  [14] stubRoutines_init1(0xffffffff7fffecf8, 0x100150d58, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7e7cbad4 
  [15] init_globals(0xffffffff7fffecf8, 0x100152008, 0x0, 0x1, 0x0, 0x0), at 0xffffffff7e0c936c 
  [16] Threads::create_vm(0xffffffff7fffefd8, 0xffffffff7ee4ca7c, 0x0, 0x100001edc, 0x0, 0x0), at 0xffffffff7e84b860 
  [17] JNI_CreateJavaVM(0xffffffff7fffeff8, 0xffffffff7ffff000, 0xffffffff7fffefd8, 0x80000001, 0x3, 0x0), at 0xffffffff7e1ddb74 
=>[18] debugJVM(), line 302 in "invoke3.cc"
  [19] main(argc = 2, argv = 0xffffffff7ffff1b8), line 90 in "invoke3.cc"


current thread: t@1
current frame:  [18]
g0-g1    0x0000000000000000 0x0000000000000003
g2-g3    0x0000000000000001 0x0000000000000000
g4-g5    0x0000000000000001 0x0000000083159800
g6-g7    0x0000000000000000 0xffffffff7c100000
o0-o1    0xffffffff7fffeff8 0xffffffff7ffff000
o2-o3    0xffffffff7fffefd8 0x0000000080000001
o4-o5    0x0000000000000003 0x0000000000000000
o6-o7    0xffffffff7fffe6b1 0x0000000100001edc
l0-l1    0xffffffff7fffefd8 0xffffffff7fffeff8
l2-l3    0xffffffff7ffff000 0x0000000000000001
l4-l5    0x0000000000008104 0x0000000000008104
l6-l7    0x000000000000000a 0x000000000000000a
i0-i1    0x0000000000000000 0xfffffffffffd0260
i2-i3    0x0000000000000000 0xffffffff7ffff40d
i4-i5    0xffffffff7ffff408 0xffffffff7cfbd051
i6-i7    0xffffffff7fffe811 0x00000001000013cc
y        0x0000000000000000
ccr      0x0000000000000044
pc       0x0000000100001edc:debugJVM+0xd4       call    JNI_CreateJavaVM [PLT]
npc      0xffffffff7cea67e4:_read+0xc   bcc,pt %icc,_read+0x28


sr1-unsh01-04{msusko}65: more hs_err_pid62747.log
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (/BUILD_AREA2/jdk1.5.0/hotspot/src/cpu/sparc/vm/assembler_sparc.inline.hpp, 424 [ Unknown ]), pid=62747
, tid=1
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0-beta2-b41-debug mixed mode)
#
# Error: assert(labs(intptr_t(d) - intptr_t(pc())) <= (intptr_t)((1 << 31 ) - 1),"target address not reachable with call 
instruction")

---------------  T H R E A D  ---------------

Current thread (0x0000000100150d58):  JavaThread  [_thread_in_vm, id=1]

Stack: [0xffffffff7ff00000,0xffffffff80000000)
[error occurred during error reporting, step 110, id 0xa]


[error occurred during error reporting, step 120, id 0xa]


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )

Other Threads:

VM state:not at safepoint (not fully initilizated)

VM Mutex/Monitor currently owned by a thread: None

Heap


interesting with just java the stack is different but the regs shows a bad address

t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
0xffffffff7eb3aa9c: JVM_handle_solaris_signal+0x0554:   ld      [%l3], %g1
Current function is debugJVM
  302           jint res = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
(dbx) where
current thread: t@1
  [1] JVM_handle_solaris_signal(0xb, 0xc438, 0xffffffff7fffda40, 0x10012bfd0, 0xffffffff7fffdd20, 0xffffffff7efcf780), at 0xffffffff7eb3aa9c 
  [2] __sighndlr(0xb, 0xffffffff7fffdd20, 0xffffffff7fffda40, 0xffffffff7eb3a410, 0x0, 0x0), at 0xffffffff7f318ae4 
  [3] call_user_handler(0xffffffff7cf00000, 0xffffffff7fffdd20, 0xffffffff7fffda40, 0x0, 0x0, 0x0), at 0xffffffff7f312718 
  [4] sigacthandler(0xb, 0xffffffff7fffdd20, 0xffffffff7fffda40, 0xffffffff7dc9ef50, 0xffffffff7f0f4000, 0x0), at 0xffffffff7f3128dc 
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [5] 0xfffffffe7ea3b1c0(0x10012bfd0, 0xb8, 0xffffffff7fffdfb0, 0xffffffff7dc9ef50, 0xffffffff7f0f4000, 0x0), at 0xfffffffe7ea3b1bf 
  [6] 0xfffffffefd417024(0x0, 0xffffffff7f1853b8, 0x0, 0x2000, 0xe6f8, 0xffffffff7fffd701), at 0xfffffffefd417023 
  [7] 0xfffffffefd40013c(0xffffffff7fffe0d8, 0xffffffff7fffe2f0, 0xa, 0xfffffffef6407e58, 0xfffffffefd40b400, 0xffffffff7fffe300), at 0xfffffffefd40013b 
  [8] JavaCalls::call_helper(0x0, 0x10012bfd0, 0xa, 0x1002138b0, 0xffffffff7fffe0f8, 0xffffffff7f0f4000), at 0xffffffff7ea6ba1c 
  [9] JavaCalls::call(0xffffffff7fffe2e8, 0x1002138b0, 0xffffffff7fffe2f8, 0x10012bfd0, 0x676140, 0xffffffff7ea15ae4), at 0xffffffff7ea7dee8 
  [10] instanceKlass::call_class_initializer_impl(0xffffffff7fffe300, 0x10012bfd0, 0xfffffffef6407e58, 0x63264c, 0x1002138b0, 0xdc00), at 0xffffffff7eac1aa8 
  [11] instanceKlass::initialize_impl(0x7, 0x10012bfd0, 0xffffffff7cd004c8, 0x100104a70, 0x0, 0xfffffffef6407ec0), at 0xffffffff7ea511d4 
  [12] instanceKlass::initialize(0x1002138a8, 0xffffffff7ea2f39c, 0x3, 0xffffffff7f1783c8, 0xffffffff7f1783c8, 0x0), at 0xffffffff7ea39048 
  [13] instanceKlass::initialize_impl(0xfffffffef6407ed0, 0x10012bfd0, 0x1001aa110, 0xfffffffef6410610, 0x0, 0xffffffff7fffe9b8), at 0xffffffff7ea50efc 
  [14] instanceKlass::initialize(0x1001aa118, 0xffffffff7ea2f39c, 0x10012bfd0, 0x1, 0xffffffff7f1783c8, 0x5b0df8), at 0xffffffff7ea39048 
  [15] Threads::create_vm(0xffffffff7f185520, 0x10012bfd0, 0x10012bfd0, 0x0, 0x11c00, 0xffffffff7f19d980), at 0xffffffff7ec547d4 
  [16] JNI_CreateJavaVM(0xffffffff7f17a484, 0x10400, 0xffffffff7fffefd8, 0x4995d8, 0xffffffff7ffff000, 0xffffffff7fffeff8), at 0xffffffff7ec5aadc 
=>[17] debugJVM(), line 302 in "invoke3.cc"
  [18] main(argc = 2, argv = 0xffffffff7ffff1b8), line 90 in "invoke3.cc"
(dbx) regs
current thread: t@1
current frame:  [17]
g0-g1    0x0000000000000000 0xffffffffffffff20
g2-g3    0x000000010012bfd0 0xfffffffef64988a8
g4-g5    0xffffffff7fffde20 0xfffffffef6407e58
g6-g7    0x0000000000000000 0xffffffff7cf00000
o0-o1    0xffffffff7f17a484 0x0000000000010400
o2-o3    0xffffffff7fffefd8 0x00000000004995d8
o4-o5    0xffffffff7ffff000 0xffffffff7fffeff8
o6-o7    0xffffffff7fffe6b1 0x0000000100001edc
l0-l1    0xffffffff7fffefd8 0xffffffff7fffeff8
l2-l3    0xffffffff7ffff000 0x0000000000000001
l4-l5    0x0000000000008104 0x0000000000008104
l6-l7    0x000000000000000a 0x000000000000000a
i0-i1    0x0000000000000000 0xfffffffffffd0260
i2-i3    0x0000000000000000 0xffffffff7ffff40d
i4-i5    0xffffffff7ffff408 0xffffffff7ddbd051
i6-i7    0xffffffff7fffe811 0x00000001000013cc
y        0x0000000000000000
ccr      0x0000000000000099
pc       0x0000000100001edc:debugJVM+0xd4       call    JNI_CreateJavaVM [PLT]
npc      0xfffffffe7ea3b1c4:0xfffffffe7ea3b1c4  <bad address 0xfffffffe7ea3b1c4>
(dbx) 

the npc shows a bad address. 

Not sure the interaction of the 64 bit nondebug vs debug JVM has on this...


                                    

Comments
EVALUATION

This bugs occurs when the codebuffer space allocated for our generated stub
code too far away to be reached by the sparc "call" instruction.

The fix is to detect this situation and generate a longer 
sequence of instructions that will guarantee that the target
can be reached.

###@###.### 2004-03-09
                                     
2004-03-09
SUGGESTED FIX

This bugs occurs when the codebuffer space allocated for our generated stub
code too far away to be reached by the sparc "call" instruction.

The fix is to detect this situation and generate a longer 
sequence of instructions that will guarantee that the target
can be reached.


###@###.### 2004-03-11
                                     
2004-03-11
WORK AROUND

This bug is caused by the fact that the VM will allocate memory for it's 
generated code when CreateJVM is called.  The VM expects this generated code
to be located within 2Gigabytes of the VM runtime routines (code section from
libjvm_g.so).  Since the test case automatically loads libjvm.so which
fixes it's code address prior to allocating it's own block of memory, the
VM's generated code cannot reach the VM runtime routines.

Since the bug mentions that the invoke3's memory allocation could be performed
after the VM creation has been completed, this is a workaround to this problem.
If the VM's initialization is performed when the program is first started,
you will not encounter this bug.

I tested moving the line  prepare_to_share_memory(numOfMKFs);
to after the call to debugJVM() and the test case passed.

###@###.### 2004-03-11
                                     
2004-03-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_05
generic
tiger-beta2

FIXED IN:
1.4.2_05
tiger-beta2

INTEGRATED IN:
1.4.2_05
tiger-beta2

VERIFIED IN:
1.4.2_05


                                     
2004-06-14



Hardware and Software, Engineered to Work Together