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

VM crashes on deoptimization



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:



        VM crashes at decompilation of a given method.
        Crash does not happen with -Xint.
        Crash does not happen with 1.4.2_02
        Crash happens with 1.4.2_04_b4 on 64 Bit

        Unexpected Signal : 10 occurred at PC=0xFFFFFFFF3841A728

        NOTE: We are unable to locate the function name symbol for the error
        just occurred. Please refer to release documentation for possible
        reason and solutions.

        Current Java thread:

        Dynamic libraries:
        0x100000000 /usr/sap/E00/JC00/j2ee/os_libs/jlaunch
        0xffffffff7f400000 /usr/lib/sparcv9/libdl.so.1
        0xffffffff7f100000 /usr/lib/sparcv9/libnsl.so.1
        0xffffffff7ef00000 /usr/lib/sparcv9/libsocket.so.1
        0xffffffff7ed00000 /usr/sap/E00/JC00/j2ee/os_libs/libsapu16_mt.so
        0xffffffff7ea00000 /usr/lib/sparcv9/libm.so.1
        0xffffffff7e800000 /usr/lib/sparcv9/libCrun.so.1
        0xffffffff7f300000 /usr/lib/sparcv9/libw.so.1
        0xffffffff7e500000 /usr/lib/sparcv9/libthread.so.1
        0xffffffff7e300000 /usr/lib/sparcv9/libc.so.1
        0xffffffff7e000000 /usr/lib/64/libmp.so.2
        0xffffffff7e700000 /usr/platform/SUNW,
        0xffffffff7db00000 /usr/sap/E00/JC00/j2ee/os_libs/libicuuc.so.20
        0xffffffff7d000000 /usr/sap/E00/JC00/j2ee/os_libs/libicudt20b.so
        0xffffffff7ce00000 /usr/lib/sparcv9/libpthread.so.1
        0xffffffff7bc00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/server/libjvm.so
        0xffffffff7ba00000 /usr/lib/64/libsched.so.1
        0xffffffff7b100000 /usr/j2sdk1.4.
        0xffffffff7af00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libverify.so
        0xffffffff7ad00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libjava.so
        0xffffffff7aa00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libzip.so
        0xfffffffeee500000 /usr/lib/locale/en_US.ISO8859-1/sparcv9/en_US.
        0xfffffffeee300000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libjdwp.so
        0xfffffffeee000000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libdt_socket.so
        0xfffffffeede00000 /usr/lib/64/nss_files.so.1
        0xfffffffee9f00000 /usr/sap/E00/JC00/j2ee/os_libs/libjperflib.so
        0xfffffffee9c00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libnet.so
        0xfffffffed4b00000 /usr/j2sdk1.4.2_04/jre/lib/sparcv9/libioser12.so
        0xfffffffecf500000 /usr/lib/64/nss_nis.so.1

        Heap at VM Abort:
        def new generation total 127232K, used 64767K [0xfffffffeeec00000,
        0xfffffffef6c00000, 0xfffffffefec00000)
        eden space 123392K, 50% used [0xfffffffeeec00000, 0xfffffffef2914580,
        from space 3840K, 57% used [0xfffffffef6480000, 0xfffffffef66ab788,
        to space 3840K, 0% used [0xfffffffef6840000, 0xfffffffef6840000,
        tenured generation total 393216K, used 320775K [0xfffffffefec00000,
        0xffffffff16c00000, 0xffffffff2ec00000)
        the space 393216K, 81% used [0xfffffffefec00000, 0xffffffff12541f48,
        0xffffffff12542000, 0xffffffff16c00000)
        compacting perm gen total 131072K, used 103876K [0xffffffff2ec00000,
        0xffffffff36c00000, 0xffffffff36c00000)
        the space 131072K, 79% used [0xffffffff2ec00000, 0xffffffff35171268,
        0xffffffff35171400, 0xffffffff36c00000)

        Local Time = Mon Mar 1 15:12:35 2004
        Elapsed Time = 1095
        # HotSpot Virtual Machine Error : 10
        # Error ID : 4F530E43505002EF 01
        # Please report this error at
        # http://java.sun.com/cgi-bin/bugreport.cgi
        # Java VM: Java HotSpot(TM) 64-Bit Server VM (20040219141514.kvn.1.4.
        2_04_sap mixed mode)
        # An error report file has been saved as hs_err_pid12523.log.
        # Please refer to the file for further information.

        ified that the crash happens during deoptimization
        of this method. Perfect. Could you, please, gzip the log and
        ask Stefan to put it where I can download it.

        And if you saw such crash in 1.4.2_01 it may not introduced
        by our fixes.

        Today I continued to analyze the core file with big help
        from Tom R. and John R.

        We got disassembled compiled code and bytecode for this method
        from the core file using SA. And, it seems, we have a problem with
        restoring expression stack during deoptimization or restarting
        process in interpreter (bytecode from wich to continue may be wrong)
        when we hit uncommon trap. It could be again the edge case which we
        never had before.

        Dirk, could you, please, rerun fastdebug JVM but WITHOUT those flags
        (it should be faster)? And use the file .hotspot_compiler with
        this print instruction:

        print com/sapportals/portal/prt/util/StringUtils escapeToJS

        It will print a pseudo-assembler code generated for this method.
        Then gzip and send it to me. It should have more info then in
        the core file.


        "Marwinski, Dirk" wrote:
        > Hi Vladimir,
        > > Ok. So we have the workaround now.
        > Our results strongly indicate this.
        > > My main concern here is this problem was introduced by our
        > > fixes or it was there before. What is puzzling me is this
        > > Stefan's comment:
        > > "This crash did never happen with the original VM 1.4.2_02."
        > > Does it mean you were able to pass the original (4985384) crash
        > > and this crash with 1.4.2_02?
        > This was in fact my statement which I took from the admin of
        > the system here. I will try to verify this myself. From what I
        > have seen, it looks that the problem did exist in 1.4.2_01, did
        > not exist in 1.4.2_02 + 03 and was re-introduced in 1.4.2_04. We
        > did have similar crashes on other systems which we could not
        > reproduce with 1.4.02_02 that did exist in 01. This is however
        > only a suspicion!
        > > Unfortunately you may not get crash with fastdebug build.
        > > You can stop testing if you can grep the log file
        > > for "{method} 'escapeToJS'". Which would mean we passed the deoptimization
        > > for this method. Stop testing also if the log file is very big:
        > > it will be difficult to analyze it anyway.
        > It did crash. The log is approx 700MB. The following is at the end:
        > ------------------------
        > DEOPT PACKING thread 0x101771678 Compiled frame (sp=0xfffffffee0ffb450, fp=0xfff
        > ffffee0ffb520, pc=0xffffffff382bb570)
        > nmethod:{method} 'escapeToJS' '(Ljava/lang/String;)Ljava/lang/String;' in '
        > com/sapportals/portal/prt/util/StringUtils'
        > Virtual frames (innermost first):
        > 0 - com.sapportals.portal.prt.util.StringUtils.escapeToJS(StringUtils.ja
        > va:90) - invokevirtual @ bci 232
        > Created vframeArray 0x103183ef8
        > DEOPT UNPACKING thread 0x101771678 vframeArray 0x103183ef8
        > {method} 'escapeToJS' '(Ljava/lang/String;)Ljava/lang/String;' in 'com/sapp
        > ortals/portal/prt/util/StringUtils' - invokevirtual @ bci 232 sp = 0xfffffffee0f
        > fb470
        > Unexpected Signal : 10 occurred at PC=0xFFFFFFFF3703604C
        > Function=[Unknown.]
        > Library=(N/A)
        > NOTE: We are unable to locate the function name symbol for the error
        > just occurred. Please refer to release documentation for possible
        > reason and solutions.
        > [...]
        > --------------------------------------------------
        > Thanks,
        > Dirk


            Issue Links



                kvn Vladimir Kozlov
                stschnei Stefan Schneider (Inactive)
                0 Vote for this issue
                2 Start watching this issue