Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5009610

64 bit JVM cores with target address not reachable with call instruction

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      05
    • CPU:
      generic
    • OS:
      solaris_8
    • Verification:
      Verified

      Backports

        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...

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                bobv Bob Vandette (Inactive)
                Reporter:
                msusko Mark Susko (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: