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

SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.<init>

    Details

    • Subcomponent:
    • Resolved In Build:
      b49

      Backports

        Description

        JDK-8047383 was fixed in 8u40b13. But issue is still reproducible.

        The hs_err head is
        #
        # A fatal error has been detected by the Java Runtime Environment:
        #
        # SIGBUS (0xa) at pc=0xffffffff712ea184, pid=4315, tid=72
        #
        # JRE version: Java(TM) SE Runtime Environment (8.0_40) (build 1.8.0_40-internal-20150109165513.amurillo.hs25-40-b24-snap-b00)
        # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.40-b24 compiled mode solaris-sparc )
        # Problematic frame:
        # J 87270 C2 weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.<init>(Lweblogic/wsee/jaxws/framework/jaxrpc/EnvironmentFactory;Lcom/sun/xml/ws/api/model/wsdl/WSDLModel;)V (313 bytes) @ 0xffffffff712ea184 [0xffffffff712e90a0+0x10e4]
        #
        # Core dump written. Default location: /export/local/aurora/sandbox/results/weblogic/core or core.4315
        #
        # If you would like to submit a bug report, please visit:
        # http://bugreport.java.com/bugreport/crash.jsp
        #

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

        Current thread (0x0000000101a37800): JavaThread "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_in_Java, id=72, stack(0xffffffff2ff00000,0xffffffff30000000)]

        siginfo: si_signo: 10 (SIGBUS), si_code: 1 (BUS_ADRALN), si_addr: 0xfffffff9adb9deac

        Registers:
         G1=0xfffffff9adc72650 G2=0x0000000101a37800 G3=0x0000000040000000 G4=0xffffffff4f91f2a8
         G5=0xffffffff4f801388 G6=0x0000000000000000 G7=0xffffffff7b213a00 Y=0x0000000000000000
         O0=0xfffffff9adc72678 O1=0xfffffff9adb9da78 O2=0xfffffff9adc71c50 O3=0xffffffff23ebf988
         O4=0xfffffff9adc72318 O5=0xff7fffff6c000000 O6=0xffffffff2fffb3f1 O7=0xffffffff712ea17c
         L0=0xfffffff9adc714c8 L1=0xfffffff9adc71310 L2=0xfffffff9adc72640 L3=0xfffffff9adb9ead8
         L4=0xfffffff9adc72678 L5=0x0000000000000005 L6=0xffffffff23dd8d48 L7=0xfffffff9adc726c0
         I0=0xfffffff9adb9def0 I1=0xfffffff9adc71310 I2=0xfffffff9adc71ce8 I3=0xffffffff23ecaa18
         I4=0xffffffff23ec8ff8 I5=0xffffffff4f912e58 I6=0xffffffff2fffb4c1 I7=0xffffffff712dfb54
         PC=0xffffffff712ea184 nPC=0xffffffff712ea188


        Top of Stack: (sp=0xffffffff2fffbbf0)
        0xffffffff2fffbbf0: fffffff9adc714c8 fffffff9adc71310
        0xffffffff2fffbc00: fffffff9adc72640 fffffff9adb9ead8
        0xffffffff2fffbc10: fffffff9adc72678 0000000000000005
        0xffffffff2fffbc20: ffffffff23dd8d48 fffffff9adc726c0
        0xffffffff2fffbc30: fffffff9adb9def0 fffffff9adc71310
        0xffffffff2fffbc40: fffffff9adc71ce8 ffffffff23ecaa18
        0xffffffff2fffbc50: ffffffff23ec8ff8 ffffffff4f912e58
        0xffffffff2fffbc60: ffffffff2fffb4c1 ffffffff712dfb54
        0xffffffff2fffbc70: fffffff9adb9b128 fffffff9adb9da78
        0xffffffff2fffbc80: fffffff9adb9dec8 0000000000000000
        0xffffffff2fffbc90: 0000000000000000 3f60115555555555
        0xffffffff2fffbca0: 41a354a000000000 41ae000000000000
        0xffffffff2fffbcb0: 0000000000000000 0000000000000000
        0xffffffff2fffbcc0: ffffffff23e29088 ffffffff23dd8d48
        0xffffffff2fffbcd0: fffffffffffffff8 fffffff9adc714c8
        0xffffffff2fffbce0: ff7fffff6c000000 ffffffff23e29088

        Instructions: (pc=0xffffffff712ea184)
        0xffffffff712ea164: c0 72 20 48 e2 72 20 10 e2 72 20 20 e2 72 20 50
        0xffffffff712ea174: a8 10 00 08 90 10 00 14 7e cb 1f d9 01 00 00 00
        0xffffffff712ea184: ee 5e 3f bc ab 35 30 09 e6 75 20 18 c0 2d c0 15
        0xffffffff712ea194: c2 58 a0 60 ea 58 a0 70 ae 00 60 40 3a ed c7 b5

        Register to memory mapping:

        G1=0xfffffff9adc72650 is an oop

        EOF

        JDK-8047383 was fixed in 8u40b13. But issue is still reproducible
        1. asm-weblogic.txt
          86 kB
          Igor Veresov
        2. asm-weblogic2.txt
          83 kB
          Igor Veresov
        3. asm-weblogic-replay.pdf
          159 kB
          Igor Veresov
        4. asm-weblogic-replay.txt
          276 kB
          Igor Veresov
        5. hs_err_pid27142.log
          42 kB
          Igor Veresov
        6. replay_pid2a26_compid87214.log
          832 kB
          Igor Veresov
        7. weblogic-stripped-cfg2.pdf
          240 kB
          Igor Veresov
        8. weblogic-stripped-cfg3.pdf
          78 kB
          Igor Veresov

          Issue Links

            Activity

            Hide
            kvn Vladimir Kozlov added a comment -
            I was more concern about data collocation when several arrays are used. But it is not critical, as you said, for small arrays. So leave it as it is.
            Show
            kvn Vladimir Kozlov added a comment - I was more concern about data collocation when several arrays are used. But it is not critical, as you said, for small arrays. So leave it as it is.
            Hide
            iveresov Igor Veresov added a comment -
            I went though a couple of more prototypes and settled on having a separate pass that is done after post-alloc copy removal. It makes it much easier because post-alloc removes copies, which means the tracking arrays need to be adjusted all the time - the nodes that use the lrgs we track can go away, as well as the nodes around them, nodes may be removed so that the MachMerge is not longer required, etc. It's quite an error-prone process with questionable computational benefits. I also switched to using a pointer to the first use instead of having an offset, since finding the node requires much less work on average (the blocks are usually quite small), as opposed to adjusting offsets in rather large arrays of max_reg size.

            So here is the best solution I have so far: http://cr.openjdk.java.net/~iveresov/8068881/webrev.01/
            Show
            iveresov Igor Veresov added a comment - I went though a couple of more prototypes and settled on having a separate pass that is done after post-alloc copy removal. It makes it much easier because post-alloc removes copies, which means the tracking arrays need to be adjusted all the time - the nodes that use the lrgs we track can go away, as well as the nodes around them, nodes may be removed so that the MachMerge is not longer required, etc. It's quite an error-prone process with questionable computational benefits. I also switched to using a pointer to the first use instead of having an offset, since finding the node requires much less work on average (the blocks are usually quite small), as opposed to adjusting offsets in rather large arrays of max_reg size. So here is the best solution I have so far: http://cr.openjdk.java.net/~iveresov/8068881/webrev.01/
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b0ce179e4a01
            User: iveresov
            Date: 2015-01-19 22:34:52 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b0ce179e4a01 User: iveresov Date: 2015-01-19 22:34:52 +0000
            Hide
            idergali Ilya Dergalin (Inactive) added a comment -
            Igor Ignatyev added a comment - 2015-01-20 21:28
            since it's a regression and crash in weblogic, SQE is ok to take it into 8u40.
            Show
            idergali Ilya Dergalin (Inactive) added a comment - Igor Ignatyev added a comment - 2015-01-20 21:28 since it's a regression and crash in weblogic, SQE is ok to take it into 8u40.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b0ce179e4a01
            User: lana
            Date: 2015-02-04 21:53:42 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b0ce179e4a01 User: lana Date: 2015-02-04 21:53:42 +0000

              People

              • Assignee:
                iveresov Igor Veresov
                Reporter:
                bmoloden Boris Molodenkov (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: