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.

Sign up for GitHub

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

Jump to bottom

Maven tests execution for org.eclipse.core.tests.compiler is often stuck #1597

Closed
mickaelistria opened this issue Nov 13, 2023 · 7 comments
Closed

Maven tests execution for org.eclipse.core.tests.compiler is often stuck #1597

mickaelistria opened this issue Nov 13, 2023 · 7 comments

Comments

@mickaelistria
Copy link
Contributor

mickaelistria commented Nov 13, 2023 •
edited
Loading

When running JDT tests with mvn verify command-line, I often see, on CI or locally, the build being stuck with

[INFO] --- tycho-surefire:4.0.4:test (default-test) @ org.eclipse.jdt.core.tests.compiler ---
[WARNING] Problems resolving provisioning plan.: [Unable to satisfy dependency from org.eclipse.jdt.core.compiler.batch 3.35.0.v20230717-1441 to osgi.ee; (&(osgi.ee=JavaSE)(version=20)).; Unable to satisfy dependency from org.osgi.service.http 1.2.2.202109301733 to java.package; javax.servlet [2.1.0,3.0.0).; Unable to satisfy dependency from org.osgi.service.http 1.2.2.202109301733 to java.package; javax.servlet.http [2.1.0,3.0.0).; Unable to satisfy dependency from org.osgi.service.http.whiteboard 1.1.1.202109301733 to osgi.contract; (&(osgi.contract=JavaServlet)(version=3.1.0)).]
[WARNING] Using JavaSE-21 to fulfill requested profile of JavaSE-17 this might lead to faulty dependency resolution, consider define a suitable JDK in the toolchains.xml
[INFO] Executing test runtime with timeout (seconds): 0, logs, if any, will be placed at: /home/mistria/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.compiler/target/work/data/.metadata/.log
[INFO] Command line:
	[/usr/lib/jvm/java-21-openjdk-21.0.0.0.35-1.rolling.fc38.x86_64/bin/java, -Dosgi.noShutdown=false, -Dosgi.os=linux, -Dosgi.ws=gtk, -Dosgi.arch=x86_64, -Dosgi.clean=true, -ea, -jar, /home/mistria/.m2/repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.6.600.v20231106-1826/org.eclipse.equinox.launcher-1.6.600.v20231106-1826.jar, -data, /home/mistria/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.compiler/target/work/data, -install, /home/mistria/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.compiler/target/work, -configuration, /home/mistria/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.compiler/target/work/configuration, -application, org.eclipse.tycho.surefire.osgibooter.headlesstest, -testproperties, /home/mistria/git/eclipse.jdt.core/org.eclipse.jdt.core.tests.compiler/target/surefire.properties]
Running org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest
reflectNestedClassUseDollar=true due to isJRE9Plus

and then nothing happening

I ran a stack on such a local case, see #1597 (comment)
@mickaelistria
Copy link
Contributor Author

@laeubi Does

 java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@21/Native Method)
	- parking to wait for  <0x000000062f61e8e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base@21/LockSupport.java:371)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base@21/AbstractQueuedSynchronizer.java:519)
	at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base@21/ForkJoinPool.java:3780)
	at java.util.concurrent.ForkJoinPool.managedBlock(java.base@21/ForkJoinPool.java:3725)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@21/AbstractQueuedSynchronizer.java:1707)
	at java.lang.ProcessImpl.waitFor(java.base@21/ProcessImpl.java:425)
	at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:364)
	at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
	at org.eclipse.sisu.equinox.launching.internal.DefaultEquinoxLauncher.execute(DefaultEquinoxLauncher.java:73)
	at org.eclipse.tycho.surefire.AbstractEclipseTestMojo.runTest(AbstractEclipseTestMojo.java:940)

relate to something known to be troublemaker in Tycho?

@laeubi
Copy link
Contributor

laeubi commented Nov 13, 2023

I think it simply waits for the test runtime to terminate... if that never happens of cause it could take long.

@mickaelistria
Copy link
Contributor Author

@laeubi OK, I looked at the wrong process, sorry (I'm removing this Tycho stack from former comment). I see the other process with jstack, look at elapsed values to see how much time is spent between stacks (very long)

"main" #1 [678387] prio=5 os_prio=0 cpu=235963.36ms elapsed=238.06s tid=0x00007f3bd4029650 nid=678387 runnable  [0x00007f3bdabfc000]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.jdt.internal.compiler.parser.Parser.consumeDefaultModifiers(Parser.java:3259)
	at org.eclipse.jdt.internal.compiler.parser.Parser.consumeRule(Parser.java:8404)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13228)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13486)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13443)
	at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:11825)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.dietParse(CompletionParser.java:5444)
	at org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest.checkParse(DietRecoveryTest.java:242)

and then later

"main" #1 [678387] prio=5 os_prio=0 cpu=285777.85ms elapsed=288.10s tid=0x00007f3bd4029650 nid=678387 runnable  [0x00007f3bdabfc000]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.jdt.internal.codeassist.impl.AssistParser.lastIndexOfElement(AssistParser.java:1939)
	at org.eclipse.jdt.internal.codeassist.impl.AssistParser.requireExtendedRecovery(AssistParser.java:2234)
	at org.eclipse.jdt.internal.codeassist.impl.AssistParser.resumeAfterRecovery(AssistParser.java:2432)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.resumeAfterRecovery(CompletionParser.java:6171)
	at org.eclipse.jdt.internal.compiler.parser.Parser.resumeOnSyntaxError(Parser.java:14614)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.resumeOnSyntaxError(CompletionParser.java:6101)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13134)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13486)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13443)
	at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:11825)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.dietParse(CompletionParser.java:5444)
	at org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest.checkParse(DietRecoveryTest.java:242)
	at org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest.test01(DietRecoveryTest.java:330)

(wait some 40 seconds)

"main" #1 [678387] prio=5 os_prio=0 cpu=345601.44ms elapsed=348.17s tid=0x00007f3bd4029650 nid=678387 runnable  [0x00007f3bdabfc000]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.completionIdentifierCheck(CompletionParser.java:2333)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.updateRecoveryState(CompletionParser.java:6222)
	at org.eclipse.jdt.internal.compiler.parser.Parser.resumeOnSyntaxError(Parser.java:14595)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.resumeOnSyntaxError(CompletionParser.java:6101)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13134)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13486)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13443)
	at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:11825)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.dietParse(CompletionParser.java:5444)
	at org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest.checkParse(DietRecoveryTest.java:242)
	at org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest.test01(DietRecoveryTest.java:330)

and

"main" #1 [678387] prio=5 os_prio=0 cpu=420500.88ms elapsed=423.40s tid=0x00007f3bd4029650 nid=678387 runnable  [0x00007f3bdabfc000]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.jdt.internal.codeassist.impl.AssistParser.lastIndexOfElement(AssistParser.java:1939)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.updateRecoveryState(CompletionParser.java:6216)
	at org.eclipse.jdt.internal.compiler.parser.Parser.resumeOnSyntaxError(Parser.java:14595)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.resumeOnSyntaxError(CompletionParser.java:6101)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13134)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13486)
	at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:13443)
	at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:11825)
	at org.eclipse.jdt.internal.codeassist.complete.CompletionParser.dietParse(CompletionParser.java:5444)
	at org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest.checkParse(DietRecoveryTest.java:242)
	at org.eclipse.jdt.core.tests.compiler.parser.DietRecoveryTest.test01(DietRecoveryTest.java:330)

and...

So it looks like there is some infinite execution here?

@mickaelistria
Copy link
Contributor Author

I see it seems to cycle in switch (resumeOnSyntaxError()) for the case RESTART.
But I cannot reproduce this error running the test with PDE.

@datho7561
Copy link
Contributor

I'm also running into this issue. I wasn't running into it in #1517, and switched to master and didn't run into it there, so it might be something specific to the PR. Given the log, it might be something with the CompletionParser. I'll investigate.

@mickaelistria
Copy link
Contributor Author

Thanks for confirming you can reproduce.
I'm not sure if it's the CompletionParser or just the enablement of recovery. I see the test doesn't provide an import, so it gets into the UnnamedClass rules. Maybe I fail at placing the right recovery instructions there?

@mickaelistria
Copy link
Contributor Author

Anyway, let's close the issue here as it's not a problem of the project, but it's a problem of the PR then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mickaelistria @laeubi @datho7561