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. hs_err_pid60182.log
          102 kB
        2. ideal.txt
          803 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: