RVM

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: