JDK-8181500 : [TESTBUG] com/sun/jdi/LineNumberInfo.java fails with ArrayIndexOutOfBoundsException
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u141,8u152,8u161,10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-06-02
  • Updated: 2019-05-22
  • Resolved: 2017-07-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 8
10 b17Fixed 8u152Fixed
Related Reports
Relates :  
Description
The failures seem to have started in JDK10 on 2017-05-23.

From the log file:

[1104ms] FAILED: Bad line number table size: jdi=36, test=35
[1104ms] FAILED: Code index mismatch: jdi=105, test=107
[1104ms] FAILED: Line number mismatch: jdi=37, test=40
[1104ms] FAILED: Code index mismatch: jdi=107, test=111
[1104ms] FAILED: Line number mismatch: jdi=40, test=41
...
[1107ms] FAILED: Code index mismatch: jdi=366, test=376
[1107ms] FAILED: Line number mismatch: jdi=73, test=75
[1107ms] FAILED: Code index mismatch: jdi=376, test=384
[1108ms] FAILED: Line number mismatch: jdi=75, test=78
java.lang.ArrayIndexOutOfBoundsException: 35
	at LineNumberInfo.runTests(LineNumberInfo.java:176)
	at TestScaffold.startTests(TestScaffold.java:431)
	at LineNumberInfo.main(LineNumberInfo.java:141)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:563)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:844)

So it looks like not only is the Line Number Table size 1 bigger than expected (this is was causes the first FAILED message and the eventually AIOOB exception), but also the line number values are not matching up with what is expected. 

Based on the error messages, it looks like there is an added Line Number Table entry at line 37, and this is causing every expected entry after that to be off by 1.

The test warns of such possible failures:

     * - this test is also sensitive to the compiler's code generation;
     *   if that changes, this test will likely need updating.

So I suspect a javac change introduced an extra entry, and the test needs to account for it.
Comments
- Justification :This is regression and this will help in smooth development and release process. - Risk Analysis : Minimal as the change in test case only. - Webrev : http://mail.openjdk.java.net/pipermail/compiler-dev/2017-July/011021.html - Testing (done) : jprt and this failing test - Back ports (done) : https://bugs.openjdk.java.net/browse/JDK-8185260 - Fix For Release : 8 CPU
31-07-2017

Is there any ETA as to when this will be pushed to jdk10/jdk10? If it's not soon then I think we have to exclude this test by adding it to the ProblemList.txt file.
18-07-2017

Reproducible with 1.8.0_141 b32 on Solaris sparcv9 so adding affected version as 8u141
17-07-2017

Yes, this can be fixed by running "javap -classpath _jj1.solaris-sparc/JTwork/classes/com/sun/jdi -l ControlFlow" and updating the lineNumbers and codeIndices table in file LineNumberInfo.java
13-07-2017

This has been failing in jdk9/dev and jdk10/jdk10 for several months, is there any way that it can be fixed in jdk10/jdk10 first? If not, then I think it will need to be excluded.
13-07-2017

From the test case comments and the code change of JDK-8180660 it is clear we have to update the test case. 42 public class LineNumberInfo extends TestScaffold { 43 /* 44 * These two arrays are used to validate the line number 45 * information returned by JDI. There are limitations to 46 * this approach: 47 * - there are no strict rules about 48 * what constitutes the "right" line number mapping, so 49 * this kind of test may have false negatives with other 50 * compilers. 51 * - this test is also sensitive to the compiler's code generation; 52 * if that changes, this test will likely need updating. 53 * - this test assumes that JDI code index == class file 54 * byte code index which may not be true in all VMs. 55 * - To find the values for these tables, compile ControlFlow.java and then 56 * do: 57 * javap -classpath _jj1.solaris-sparc/JTwork/classes/com/sun/jdi \ 58 * -l ControlFlow 59 */
13-07-2017

This issue is reproducible in 8u152 b05 onwards also In JDK9 issue is not there, as regression caused task is not yet backported to JDK9
06-07-2017

As it is a regression and it affected different versions, increasing the priority to P2.
06-07-2017

It is a regression caused by JDK-8180660
06-07-2017