RVM

Array index out of bounds in BC2IR generation context

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.0
  • Component/s: Compiler: Optimizing
  • Labels:
    None
  • Number of attachments :
    0

Description

An example of the bug is here:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4483/production/default/perf-jbb2000/jbb2000GC/1/Output.txt

there appears to be a mismatch between the number of operands returned by the Call instruction and those expected by the method.

Issue Links

This issue relates to:
RVM-288 Assertion failure in inline oracle Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment -

This is becoming a fairly dependable failure that we should aim to close by 3.0. Another example here:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4544/production/default/perf-jbb2000/jbb2000GC/1/Output.txt

I've tried repeating the error with the OTH and failed. spec/jbb/TransactionManager.go is a long method making it difficult to pinpoint the inlining problem. Related bug statements added in r14769, r14807 and r14808.

Show
Ian Rogers added a comment - This is becoming a fairly dependable failure that we should aim to close by 3.0. Another example here: http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4544/production/default/perf-jbb2000/jbb2000GC/1/Output.txt I've tried repeating the error with the OTH and failed. spec/jbb/TransactionManager.go is a long method making it difficult to pinpoint the inlining problem. Related bug statements added in r14769, r14807 and r14808.
Hide
Permalink
Ian Rogers added a comment -

An example of the error:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4550/production/default/perf-jbb2000/jbb2000GC/1/Output.txt

what appears to be happening is a call from spec.jbb.TransactionManager.go is getting the wrong targets. Ie in the bytecode:

665: invokevirtual #105; //Method spec/jbb/NewOrderTransaction.process)Z
668: pop
669: aload 32
671: invokevirtual #117; //Method spec/jbb/NewOrderTransaction.secondDisplay)V
674: invokestatic #65; //Method java/lang/System.currentTimeMillis)J
677: lstore 9
679: lload 9
681: lload 7
683: lsub
684: lstore 11
686: aload_0
687: getfield #61; //Field company:Lspec/jbb/Company;
690: getfield #97; //Field spec/jbb/Company.mode:B
693: iconst_2
694: if_icmpne 706
697: aload 24
699: iload 13
701: lload 11
703: invokevirtual #124; //Method spec/jbb/TimerData.updateTimerData:(IJ)V

the call to process() at PC=665 is returning the methods from updateTimerData at PC=703. There are similar sequence elsewhere in the very large go method but always the distance between the bytecodes appears to be 38.

I believe the cause of the bug may be OSR, this is what makes it hard to reproduce. I think OSR may have inserted extra bytecodes into go (probably 38 of them) and by a fluke this means that when we ask for targets of process we get them for a method that is 38bytes later.

Show
Ian Rogers added a comment - An example of the error: http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/4550/production/default/perf-jbb2000/jbb2000GC/1/Output.txt what appears to be happening is a call from spec.jbb.TransactionManager.go is getting the wrong targets. Ie in the bytecode: 665: invokevirtual #105; //Method spec/jbb/NewOrderTransaction.process)Z 668: pop 669: aload 32 671: invokevirtual #117; //Method spec/jbb/NewOrderTransaction.secondDisplay)V 674: invokestatic #65; //Method java/lang/System.currentTimeMillis)J 677: lstore 9 679: lload 9 681: lload 7 683: lsub 684: lstore 11 686: aload_0 687: getfield #61; //Field company:Lspec/jbb/Company; 690: getfield #97; //Field spec/jbb/Company.mode:B 693: iconst_2 694: if_icmpne 706 697: aload 24 699: iload 13 701: lload 11 703: invokevirtual #124; //Method spec/jbb/TimerData.updateTimerData:(IJ)V the call to process() at PC=665 is returning the methods from updateTimerData at PC=703. There are similar sequence elsewhere in the very large go method but always the distance between the bytecodes appears to be 38. I believe the cause of the bug may be OSR, this is what makes it hard to reproduce. I think OSR may have inserted extra bytecodes into go (probably 38 of them) and by a fluke this means that when we ask for targets of process we get them for a method that is 38bytes later.
Hide
Permalink
Ian Rogers added a comment -

There is a bug that the callHelper in BC2IR doesn't take into account the bciAdjustment of OSR, we can therefore currently get the wrong targets for a method called during OSR from the adaptive systems weighted call graph (which quite logically doesn't know anything about OSR bytecode adjustments). We know SPECjbb2000 is likely to be hitting this problem because of the array index out of bounds exception, bloat could be getting this problem too, but perversely the called method and the wrong target methods may have the same or a greater number of arguments.

Show
Ian Rogers added a comment - There is a bug that the callHelper in BC2IR doesn't take into account the bciAdjustment of OSR, we can therefore currently get the wrong targets for a method called during OSR from the adaptive systems weighted call graph (which quite logically doesn't know anything about OSR bytecode adjustments). We know SPECjbb2000 is likely to be hitting this problem because of the array index out of bounds exception, bloat could be getting this problem too, but perversely the called method and the wrong target methods may have the same or a greater number of arguments.
Hide
Permalink
Ian Rogers added a comment -

Fix committed in r14811. Will close after some regression tests go by.

Show
Ian Rogers added a comment - Fix committed in r14811. Will close after some regression tests go by.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.