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

dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 0) failed: Bad size calculated"

    Details

    • Subcomponent:
    • Introduced In Build:
      b07
    • Introduced In Version:
      9
    • Resolved In Build:
      b11
    • CPU:
      x86_64, sparc_64
    • OS:
      solaris

      Backports

        Description

        dtrace/hotspot/Monitors/Monitors001

            Assert failure twice on Solaris x64 and twice on Solaris sparc:
                # Internal Error (/opt/jprt/T/P1/205720.cphillim/s/src/share/vm/oops/oop.inline.hpp:485), pid=26979, tid=2
                # assert(s > 0) failed: Bad size calculated
                #
                # JRE version: (9.0-b07) (build )
                # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b62-internal-201404092057.cphillim.rt-gz-sleep-fastdebug compiled mode solaris-amd64 )
                # Core dump written. Default location: /export/local/aurora/sandbox/results/ResultDir/Monitors001/core or core.26979
                #
                # If you would like to submit a bug report, please visit:
                # http://bugreport.sun.com/bugreport/crash.jsp
                #

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

                Current thread (0x0000000000422000): JavaThread "Unknown thread" [_thread_in_vm, id=2, stack(0xfffffd7ffb88f000,0xfffffd7ffb98f000)]

                Stack: [0xfffffd7ffb88f000,0xfffffd7ffb98f000], sp=0xfffffd7ffb98b1a0, free space=1008k
                Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
                V [libjvm.so+0x29f0b5c] void VMError::report(outputStream*)+0x92c;; __1cHVMErrorGreport6MpnMoutputStream__v_+0x92c
                V [libjvm.so+0x29f2121] void VMError::report_and_die()+0x579;; __1cHVMErrorOreport_and_die6M_v_+0x579
                V [libjvm.so+0x106ff3b] void report_vm_error(const char*,int,const char*,const char*)+0x55f;; __1cPreport_vm_error6Fpkci11_v_+0x55f
                V [libjvm.so+0x26374d6] int SharedRuntime::dtrace_object_alloc(oopDesc*)+0x896;; __1cNSharedRuntimeTdtrace_object_alloc6FpnHoopDesc__i_+0x896
                V [libjvm.so+0x1617219] instanceOop InstanceMirrorKlass::allocate_instance(KlassHandle,Thread*)+0xb95;; __1cTInstanceMirrorKlassRallocate_instance6MnLKlassHandle_pnGThread__nLinstanceOop__+0xb95
                V [libjvm.so+0x17d032b] oop java_lang_Class::create_basic_type_mirror(const char*,BasicType,Thread*)+0x83;; __1cPjava_lang_ClassYcreate_basic_type_mirror6FpkcnJBasicType_pnGThread__nDoop__+0x83
                V [libjvm.so+0x28e5625] void Universe::initialize_basic_type_mirrors(Thread*)+0x49;; __1cIUniversebDinitialize_basic_type_mirrors6FpnGThread__v_+0x49
                V [libjvm.so+0x27c1c45] void SystemDictionary::initialize_preloaded_classes(Thread*)+0xac9;; __1cQSystemDictionarybCinitialize_preloaded_classes6FpnGThread__v_+0xac9
                V [libjvm.so+0x27bf0bc] void SystemDictionary::initialize(Thread*)+0x4b0;; __1cQSystemDictionaryKinitialize6FpnGThread__v_+0x4b0
                V [libjvm.so+0x28e2361] void Universe::genesis(Thread*)+0xd45;; __1cIUniverseHgenesis6FpnGThread__v_+0xd45
                V [libjvm.so+0x28eb97c] void universe2_init()+0x2c;; __1cOuniverse2_init6F_v_+0x2c
                V [libjvm.so+0x149a718] int init_globals()+0xd4;; __1cMinit_globals6F_i_+0xd4
                V [libjvm.so+0x2858230] int Threads::create_vm(JavaVMInitArgs*,bool*)+0x1f8;; __1cHThreadsJcreate_vm6FpnOJavaVMInitArgs_pb_i_+0x1f8
                V [libjvm.so+0x19f1489] JNI_CreateJavaVM+0x81;; JNI_CreateJavaVM+0x81
                C [libjli.so+0x9ed1] InitializeJVM+0x109;; InitializeJVM+0x109
                C [libjli.so+0x7d78] JavaMain+0x5c;; JavaMain+0x5c
                C [libc.so.1+0xdd60b] _thr_setup+0x5b;; _thr_setup+0x5b
                C [libc.so.1+0xdd840] _lwp_start+0x0;; _lwp_start+0x0

            Could be related to the fix for JDK-8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool), which moved where the size is set for java/lang/Class-objects (thanks mgerdin!).
            Similar failure can also be seen in JDK-7005510: DynamicProbes01 fails with "assert(DTraceAllocProbes) failed: wrong call", although I don't know if it's the same underlying issue.

            Host: burgc14, Intel x86 3059 MHz, 24 cores, 144G, Solaris / Solaris 10, i86pc
            Host: vm-t1000-01, Sun Sparcv9 1000 MHz, 24 cores, 2G, Solaris / Solaris 10, sun4v
            Options: -d64 -server -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops -XX:ReservedCodeCacheSize=256M

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  coleenp Coleen Phillimore
                  Reporter:
                  allwin Peter Allwin (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: