Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[23] many errors, some failure in AutomatedTestSuite with latest from JDT/Core #1639

Closed
stephan-herrmann opened this issue Sep 11, 2024 · 7 comments
Milestone

Comments

@stephan-herrmann
Copy link
Contributor

After seeing 478 failures in https://ci.eclipse.org/releng/job/YPBuilds/job/ep433Y-unit-cen64-gtk3-java23/lastCompletedBuild/testReport/ I succeeded to reproduce 415 such locally with latest from BETA_JAVA23 of relevant JDT projects.

@stephan-herrmann
Copy link
Contributor Author

Those are Heisenbugs: they reliably fail except when run in debug mode :(

@stephan-herrmann
Copy link
Contributor Author

Those are Heisenbugs: they reliably fail except when run in debug mode :(

Wow, hard-core Heisenbug, no debugger needed to send the bug into hiding:

  • throws NPE:
	final int getExtendedEnd(ASTNode node) {
		TargetSourceRangeComputer.SourceRange range= getExtendedRange(node);
		return range.getStartPosition() + range.getLength();
	}
  • does not throw NPE:
	final int getExtendedEnd(ASTNode node) {
		TargetSourceRangeComputer.SourceRange range= getExtendedRange(node);
		if (range == null) {
			System.out.println();
		}
		return range.getStartPosition() + range.getLength();
	}

@stephan-herrmann
Copy link
Contributor Author

The null in question is produced by this method in NoCommentSourceRangeComputer:

	public SourceRange computeSourceRange(ASTNode node) {
		return new SourceRange(node.getStartPosition(), node.getLength());
	}

For lack of debugability I reduced the test suite to

  • AutomatedSuite - no change
    • CoreTestSuite - disable (remove or comment) all except SourceActionTests
      • SourceActionTests - keep only:
        • AddUnimplementedMethodsTest
        • GenerateGettersSettersTest16
        • GenerateDelegateMethodsTest
        • AddUnimplementedConstructorsTest
        • QuickFixTestSuite only the first two classes are needed:
          • QuickFixTest9
          • QuickFixTest1d8

At that point I could disable GC to reduce non-determinism:

-Xmx4G
-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

With this setup, the error was fairly stable, but the boarder of what tests could be removed without "breaking" the bug was not 100% deterministic.

Finally I added the following harness in ASTRewriteAnalyzer:

	final int getExtendedEnd(ASTNode node) {
		try {
			TargetSourceRangeComputer.SourceRange range= getExtendedRange(node);
			return range.getStartPosition() + range.getLength();
		} catch (NullPointerException npe) {
			System.err.println(extendedSourceRangeComputer);
			npe.printStackTrace();
			System.err.println(extendedSourceRangeComputer.computeSourceRange(node));
			System.err.flush();
			System.exit(-13);
		}
	}

See the implementation of getExtendedRange():

	final SourceRange getExtendedRange(ASTNode node) {
		if (this.eventStore.isRangeCopyPlaceholder(node)) {
			return new SourceRange(node.getStartPosition(), node.getLength());
		}
		return this.extendedSourceRangeComputer.computeSourceRange(node);
	}

and be told that the field extendedSourceRangeComputer is final.

Output is:

org.eclipse.jdt.internal.corext.refactoring.util.NoCommentSourceRangeComputer@5be09f8
java.lang.NullPointerException: Cannot invoke "org.eclipse.jdt.core.dom.rewrite.TargetSourceRangeComputer$SourceRange.getStartPosition()" because "range" is null
	at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.getExtendedEnd(ASTRewriteAnalyzer.java:275)
	at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisit(ASTRewriteAnalyzer.java:439)
	at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisitList(ASTRewriteAnalyzer.java:476)
	at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.voidVisit(ASTRewriteAnalyzer.java:470)
	at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.doVisitUnchangedChildren(ASTRewriteAnalyzer.java:483)
	at org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer.visit(ASTRewriteAnalyzer.java:4150)
	at org.eclipse.jdt.core.dom.VariableDeclarationStatement.accept0(VariableDeclarationStatement.java:246)
[...]
org.eclipse.jdt.core.dom.rewrite.TargetSourceRangeComputer$SourceRange@4348b168

This reports the following sequence of events:

  • getExtendedRange(node) returns null which comes from one of
    • new SourceRange(node.getStartPosition(), node.getLength()) -- funny, huh?
    • this.extendedSourceRangeComputer.computeSourceRange(node);
  • final field extendedSourceRangeComputer holds an instance of NoCommentSourceRangeComputer (see implementation at the top of this comment)
  • invoking extendedSourceRangeComputer.computeSourceRange(node) returns an instance of TargetSourceRangeComputer$SourceRange

Ergo: the null cannot possibly have happened. Yet NPE was thrown.

Noting furthermore that the errors occur only when running on JDK 23. Noting furthermore that we don't have a lot of alternatives of JDK 23 (only openjdk EA available at this point).

I'll be researching options to disable JIT for some code parts...

@stephan-herrmann
Copy link
Contributor Author

stephan-herrmann commented Sep 11, 2024

I'll be researching options to disable JIT for some code parts...

This helps:

-XX:CompileCommand=exclude,org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer::getExtendedRange

Ergo: JIT bug 👀

If others can verify, then we will have to add a BIG ALERT in some top-level documentation (once Java 23 is GA).

I'll play with p2.inf for adding these options when installing the java23 patch...

stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.ui that referenced this issue Sep 11, 2024
JDT/Core

+ add jit-exclusion to circumvent JIT-bug

fixes eclipse-jdt#1639
stephan-herrmann added a commit that referenced this issue Sep 11, 2024
… JDT/Core (#1641)

+ add jit-exclusion to circumvent JIT-bug

fixes #1639
@stephan-herrmann
Copy link
Contributor Author

Let's wait for next test results from https://ci.eclipse.org/releng/job/YPBuilds/job/ep433Y-unit-cen64-gtk3-java23/lastCompletedBuild/testReport/ (which seems to be the only job that runs tests on Java 23).

@stephan-herrmann
Copy link
Contributor Author

Let's wait for next test results from https://ci.eclipse.org/releng/job/YPBuilds/job/ep433Y-unit-cen64-gtk3-java23/lastCompletedBuild/testReport/ (which seems to be the only job that runs tests on Java 23).

https://ci.eclipse.org/releng/job/YPBuilds/job/ep433Y-unit-cen64-gtk3-java23/23/ still shows 458 failures / errors. It seems pom.xml isn't used during that build but test.xml. Trying to cover that path, too, via #1642

stephan-herrmann added a commit that referenced this issue Sep 12, 2024
… JDT/Core

add jit-exclusion also to test.xml for production test runs (#1642)

Fixes #1639
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.ui that referenced this issue Sep 13, 2024
JDT/Core

move jit-exclusion to the correct ant target (hopefully)

fixes eclipse-jdt#1639
stephan-herrmann added a commit that referenced this issue Sep 13, 2024
… JDT/Core (#1646)

move jit-exclusion to the correct ant target (hopefully)

fixes #1639
@stephan-herrmann
Copy link
Contributor Author

YES, finally the JIT-bug workaround worked, latest test run https://ci.eclipse.org/releng/job/YPBuilds/job/ep433Y-unit-cen64-gtk3-java23/25/testReport/ is down to 6 failures total, of which only 6 are in JDT (Core).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant