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

C2 crash due to SIGSEGV in PhaseIdealLoop::build_loop_late_post()

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Cannot Reproduce
    • Affects Version/s: 5.0u19, 5.0u20, 5.0u23
    • Fix Version/s: None
    • Component/s: hotspot
    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris, solaris_9, solaris_10

      Description

      OPERATING SYSTEM
      ----------------
      Solaris 10 Sparc

      JDK VERSION
      -----------
      Problem appeared in 1.5.0_18 or 1.5.0_19.
      Not reproducible with 1.5.0_17.
      Reproducible with 1.5.0_23.

      PROBLEM DESCRIPTION
      -------------------
      VM process crashes frequently in our customer's environment when compiling a Java method. The method being compiled varies, so method exclusion is not a feasible workaround - every time we exclude a method the crash occurs in another method. As this is a 64bit environment, the Client compiler is also not an option.

      Here is an example stack trace:

      =======================================================================
       ffffffff7f0ca124 _lwp_kill (6, 0, ffffffff7f0ad9d0, ffffffff7f1e0000, ffffffffffffffff, 1800) + 8
       ffffffff7f04620c abort (1, 1b8, ffffffff7e7d08e8, 199f00, 0, 0) + 118
       ffffffff7e7ca500 __1cCosFabort6Fi_v_ (1, fc00, e, ffffffff7ea34000, 269b54, b400) + 60
       ffffffff7e863528 __1cHVMErrorOreport_and_die6M_v_ (0, ffffffff7eae5c3c, ffffffff7eae5c08, ffffffff7e922144, ffffffff7ead9e50, 0) + c68
       ffffffff7e376038 JVM_handle_solaris_signal (b, 13078, ffffffff125fd2c0, 1002f7d60, ffffffff125fd5a0, 10800) + b08
       ffffffff7f0c9030 __sighndlr (b, ffffffff125fd5a0, ffffffff125fd2c0, ffffffff7e375500, 0, a) + c
       ffffffff7f0bd7a4 call_user_handler (ffffffff13101c00, ffffffff13101c00, ffffffff125fd2c0, c, 0, 0) + 3e0
       ffffffff7e1ef8ac __1cOPhaseIdealLoopUbuild_loop_late_post6MpnENode_pk0_v_ (ffffffff125fdec0, 0, 10057ee28, 0, ffffffff125fdee0, 100b6db18) + 384
       ffffffff7e310854 __1cOPhaseIdealLoopPbuild_loop_late6MrnJVectorSet_rnJNode_List_rnKNode_Stack_pk0_v_ (ffffffff125fdec0, ffffffff125fd950, ffffffff125fd8f0, ffffffff125fd910, 0, 101701980) + 28c
       ffffffff7e30d1bc __1cOPhaseIdealLoop2t5B6MrnMPhaseIterGVN_pk0i_v_ (ffffffff125fdec0, 0, 0, ffffffff125fdec8, ffffffff125fd8f0, ffffffff125fd950) + bb4
       ffffffff7e38d138 __1cHCompileIOptimize6M_v_ (ffffffff125fea40, 10022b7f0, 6a70c4, 0, f800, ffffffff7e8b69af) + 208
       ffffffff7e39025c __1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_ (ffffffff125fea40, 0, ffffffff125ff9a8, 1016c6ab8, 0, 9f8) + c3c
       ffffffff7e386864 __1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_ (ffffffff125ff9a8, ffffffff7e89f010, 101df94b0, ffffffffffffffff, 1002e18f0, ffffffff125febe0) + b4
       ffffffff7e386e2c __1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_ (101df94b0, 10022b7f0, 1002f7d60, 0, ffffffff7ead8520, ffffffff7ea34000) + 504
       ffffffff7e454740 __1cNCompileBrokerUcompiler_thread_loop6F_v_ (ffffffff7ead8520, 10022b700, 1002f7d60, 1002f8470, ffffffff7eac2c48, ffffffff7eac2c4c) + 450
       ffffffff7e3ed6c4 __1cKJavaThreadDrun6M_v_ (1002f7d60, f000, ffffffff7eacdbdc, 0, 0, ffffffff7ea34000) + 2ac
       ffffffff7e7c9f90 __1cG_start6Fpv_0_ (1002f7d60, b460, b000, b3f8, ffffffff7ead9674, ffffffff7ea34000) + 210
       ffffffff7f0c8f04 _lwp_start (0, 0, 0, 0, 0, 0)
      =======================================================================

      This crash did not occur in earlier 5.0 releases, and we've narrowed its introduction down to either 1.5.0_18 or 1.5.0_19. Therefore the prime suspects are the compiler fixes in 1.5.0_19:

      6260293: fix set_ctrl() inconsistencies in loopopts
      6394438: crash in C2 compiler in MachSpillCopyNode::implementation on 5.0_U4
      6435614: code fails with impossible ArrayIndexOutOfBounds Exception
      6754146: 1.5.0_15 C2 compiler crashes in PhaseChaitin::Split()
      6788347: C2Compiler crash 6u7
      6798785: Crash in OopFlow::build_oop_map: incorrect comparison of 64bit pointers

      (there are no compiler changes on the 1.5.0_18 release notes)

      Full core file and associated crash data available on request.

      There are a few existing CRs which include similar crash stack traces:

      6903416
      6788347 (fixed in 1.5.0_19)
      6922056
      6891431

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dsamersoff Dmitriy Samersoff
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: