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

SEGV in PhaseChaitin::post_allocate_copy_removal

XMLWordPrintable

      A crash of this kind appears to have been floating around for some time but I just caught a core file for it against JDK17 on the mac. I don't see any fix for something like this in more recent builds but maybe I missed it? The replay file was corrupted because it safepointed during replay dumping and I had to kill it. The compressed core file is about 1.7G as this occurred against a Graal build, it failed using a labsjdk based on 17.0.8+2-LTS. I can upload this somewhere along with the associated JDK image if someone would like to investigate. I did manage to get an ideal dump from hsdb and from a little examination in the debugger it appears to be a dangling MachProj from an uncommon trap MachJavaCallNode. This is the MachProj
      (lldb) p *(MachProjNode*)_cfg._blocks._blocks[660][0]._nodes._nodes[11]
      (MachProjNode) $24 = {
        ProjNode = {
          Node = {
            _in = 0x00007fe6961fa458
            _out = 0xffffffffffffffff
            _cnt = 1
            _max = 1
            _outcnt = 0
            _outmax = 0
            _idx = 10524
            _class_id = 520
            _flags = 64
          }
          _con = 6
          _is_io_use = false
        }
        _rout = {
           = {
            _RM_I = {
              [0] = 1061158911
              [1] = -1
              [2] = -1
              [3] = -1
              [4] = -1
              [5] = -1
              [6] = -1
              [7] = -1
              [8] = -1
              [9] = -1
              [10] = -1
              [11] = -1
              [12] = -1
              [13] = -1
              [14] = -1
              [15] = -1
              [16] = -1
              [17] = 32767
              [18] = 0
              [19] = 0
              [20] = 0
              [21] = 0
            }
            _RM_UP = ([0] = 18446744070475743231, [1] = 18446744073709551615, [2] = 18446744073709551615, [3] = 18446744073709551615, [4] = 18446744073709551615, [5] = 18446744073709551615, [6] = 18446744073709551615, [7] = 18446744073709551615, [8] = 140737488355327, [9] = 0, [10] = 0)
          }
          _lwm = 0
          _hwm = 8
        }
        _ideal_reg = 999
      }
      and it dies here in postaloc.cpp because lrgs(lidx) returns null
         709 // Update the register defined by this instruction
      -> 710 OptoReg::Name nreg = lrgs(lidx).reg();

      You can see it has no users but it's referenced from a live node. Anyway, if this sounds like something already fixed then great but if you want the artifacts for investigation let me know where to upload them.

        1. ideal.txt
          803 kB
        2. hs_err_pid60182.log
          102 kB
        3. replay.txt.save
          2.67 MB

            thartmann Tobias Hartmann
            never Tom Rodriguez
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: