RVM
  1. RVM
  2. RVM-145

Intermittent crash on SPECjvm98 where cattrack misses output

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      We are getting an intermittent crash in SPECjvm98 that fails due to a "EXIT_STATUS_DUMP_STACK_AND_DIE" unfortunately our test infrastructure does not seem to be capturing all output (or maybe the RVM is not outputting - difficult to determine as I keep missing opportunity to grab ant output prior to it being overwritten by next run. Not sure if this is related to RVM-104

      http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/commit.591/production/Performance/SPECjvm98/SPECjvm98

        Activity

        Hide
        Daniel Frampton added a comment -

        From the times i have gone and looked at the raw output (2 or three times), it appears to be a copyObject hardware trap from GC when tracing the root locations.

        If we are going to truncate files between the -output.txt and cattrack, we should probably drop the start rather than the end? What do people think? Peter, how hard is this to do?

        Show
        Daniel Frampton added a comment - From the times i have gone and looked at the raw output (2 or three times), it appears to be a copyObject hardware trap from GC when tracing the root locations. If we are going to truncate files between the -output.txt and cattrack, we should probably drop the start rather than the end? What do people think? Peter, how hard is this to do?
        Hide
        Peter Donald added a comment -

        Oh - I hadn't realized that it was due to truncation. We could modify truncate to get last bit but I would prefer that we increased the size of valid input so that it included all input for valid for this test. (We could make it configurable and have this test override max size of file). All that truncate was trying to stop was when we get a recursive stack error (has happened with OOMs before) that we don't try to put output of complete 20 minutes of OOM traces.

        Will not have a chance to do this until the end of the week so if you want to increase the size that would be great!

        Show
        Peter Donald added a comment - Oh - I hadn't realized that it was due to truncation. We could modify truncate to get last bit but I would prefer that we increased the size of valid input so that it included all input for valid for this test. (We could make it configurable and have this test override max size of file). All that truncate was trying to stop was when we get a recursive stack error (has happened with OOMs before) that we don't try to put output of complete 20 minutes of OOM traces. Will not have a chance to do this until the end of the week so if you want to increase the size that would be great!
        Hide
        David Grove added a comment -

        I haven't seen cattrack truncating output in an unreasonable way for a long time, so don't think the cattrack part of this is really an issue we need to track anymore.

        Show
        David Grove added a comment - I haven't seen cattrack truncating output in an unreasonable way for a long time, so don't think the cattrack part of this is really an issue we need to track anymore.

          People

          • Assignee:
            Unassigned
            Reporter:
            Peter Donald
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: