Broken pipe error when running Gradle test - java

I've got a problem regarding running tests in gradle. I know that in other machines my gradle config works but in mine unfortunately not. We have got junit test and testNG and both of them, when try to execute, produces stacktrace like this:
Could not write standard input into: Gradle Worker 1.
java.io.IOException: The pipe is being closed
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:318)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.gradle.process.internal.streams.ExecOutputHandleRunner.run(ExecOutputHandleRunner.java:53)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Which continuously will produce this error with different number (Gradle Worker 2, Gradle Worker 3, etc). Has anybody ever faced similar problem?
I'm using gradle 1.6.
EDIT: I forgot to tell that I'm using gradle wrapper
EDIT: After changing to version 1.12 I'm receiving error:
Caused by: org.gradle.api.InvalidUserDataException: Could not create task '(custome taks name)': Unknown argument(s) in task definition: [mustRunAfter]
11:20:17.990 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.TaskFactory.validateArgs(TaskFactory.java:147)
11:20:17.991 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.TaskFactory.checkTaskArgsAndCreateDefaultValues(TaskFactory.java:134)
11:20:17.991 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.TaskFactory.createTask(TaskFactory.java:72)
EDIT: Ok I think I have found what cause this problem - it was Antivirus. When I disable it script moves a little bit forward but ended with:
org.gradle.messaging.remote.internal.ConnectException: Could not connect to server [e42b57ea-ced6-4bb6-9369-3186ab4983d6 port:63631, addresses:[/127.0.0.1, /0:0:0:0:0:0:0:1]]. Tried addresses: [/127.0.0.1, /0:0:0:0:0:0:0:1].
at org.gradle.messaging.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:62)
at org.gradle.messaging.remote.internal.hub.MessageHubBackedClient.getConnection(MessageHubBackedClient.java:35)
at org.gradle.process.internal.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:54)
at org.gradle.process.internal.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:35)
at org.gradle.process.internal.child.ImplementationClassLoaderWorker.execute(ImplementationClassLoaderWorker.java:85)
at org.gradle.process.internal.child.ImplementationClassLoaderWorker.execute(ImplementationClassLoaderWorker.java:41)
at org.gradle.process.internal.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:43)
at org.gradle.process.internal.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:32)
at org.gradle.process.internal.launcher.BootstrapClassLoaderWorker.call(BootstrapClassLoaderWorker.java:46)
at org.gradle.process.internal.launcher.BootstrapClassLoaderWorker.call(BootstrapClassLoaderWorker.java:32)
at jarjar.org.gradle.process.internal.launcher.GradleWorkerMain.run(GradleWorkerMain.java:32)
at jarjar.org.gradle.process.internal.launcher.GradleWorkerMain.main(GradleWorkerMain.java:37)
Caused by: java.net.ConnectException: Connection refused: connect
Searching with google on this error gives me nothing (only some old gradle 1.1 errors info). Anybody faced this kind of problem?

Whew, after whole day struggling with gradle I think I've finally found what cause problems. Guilty of that was antivirus - COMODO. After uninstalling it and installing another one, everything started to working fine. So all Gradle Users - please be careful with COMODO because even disabled, it could cause problems when using Gradle . Be aware :)

I faced the similar issue while running the test classes. I can able to build the project, but I couldn't able to run, so after some research I found one of the solution, which is to remove the some of the workerThread-jar from the .gradle/cache folder. I tried and it worked for me. You can use below commands to solve this.
In terminal I invoked gradle test --info command,
In response, I receive the logs, where I searched the for the
Gradle worker Daemon
key, to fetch the location of my gradle-worker.jar. Typically in windows you can find this under the following location C:\Users\.gradle\caches\\workerMain\gradle-worker.jar.
To fix this, one approach is to remove the the workerMain folder itself, and run the test classes.

You really don't need to disable or remove COMODO Antivirus. Just do the following steps:
Go to COMODO Client Panel
Open the Advanced Tasks option under the Task menu.
See all active tasks and select the Gradle process that is being blocked.
Right click on the task and 'Add to Trusted Files'

I got this same error, except it said Gradle Worker 2. I restarted my command line (powershell) and then tried to build again with gradle and it worked. I had changed my environment variables to point to the Java version the project was expecting and had not thought to restart- not sure if that had anything to do with it.

None of the other answers here were helpful in my case.
What I had to do was disable the coroutine agent.
Open Settings (File - Settings)
Select Kotlin under Build... - Debugger - Data Views
Check the box "Disable coroutine agent"
Alternatively, go to your build.gradle file and upgrade the version used for the coroutines dependencies.

Related

How to launch locally built metals language server?

I am trying to set up emacs as scala editor. To that end i am trying to install metals for corresponding modes to work.
However, for some reason or another, metals either failed to install from emacs, or when installed with Coursier, were not responsive from emacs.
So, to explore all the options i decided to use metals source code (from Github? but i have run into the issue of being unable to properly utilize them.
What can i do to make metals available to emacs from the sources?
Currently, i have tried building them with
sbt publishLocal
and then trying to run the jar that was generated, with predictable result:
Exception in thread "main" java.lang.NoClassDefFoundError:
scala/collection/Seq at scala.meta.metals.Main.main(Main.scala)
Caused by: java.lang.ClassNotFoundException: scala.collection.Seq at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 1 more
Process metals stderr finished Exception in thread "main"
java.lang.NoClassDefFoundError: scala/collection/Seq at
scala.meta.metals.Main.main(Main.scala) Caused by:
java.lang.ClassNotFoundException: scala.collection.Seq at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 1 more
Process metals stderr finished
In my system i have installed with sbt, as suggested by the instructions on scala website.
How should i setup the system so that metals could be launched and used?
You shouldn't need to compile Metals from sources just to use it from Emacs. Check the official documentation: Emacs | Metals, especially the requirements and installation sections. It mentions
Next you have to install metals server. Emacs can do it for you when lsp-mode is enabled in a scala buffer or via lsp-install-server command. Also you can do it manually executing coursier install metals and configuring $PATH variable properly.
If you have problems with the installation, try asking on Scalameta Discord for help. There is a dedicated #emacs-users channel as well.
That said, if you still want to use a locally published Metals artifact for whatever other reason (e.g. contributing to the Metals code and testing changes locally), you should be able to do that. The contributing documentation describes how to work with the codebase and test your local Metals version.
In short, after you ran sbt publishLocal, you need to update the server version setting in your editor and run the Metals: Restart server command. It should pick up the locally published version.

IntelliJ 2019.2.2: Unable to debug gradle unit tests

Every time I try to debug one of my tests (junit 5), I get an exception:
2019-12-20 10:40:53,776 [4972237] WARN - .ExternalSystemTaskDebugRunner - Interrupted function call: accept failed
java.net.SocketException: Interrupted function call: accept failed
at java.base/java.net.PlainSocketImpl.accept0(Native Method)
at java.base/java.net.PlainSocketImpl.socketAccept(PlainSocketImpl.java:159)
at java.base/java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:458)
at java.base/java.net.ServerSocket.implAccept(ServerSocket.java:551)
at java.base/java.net.ServerSocket.accept(ServerSocket.java:519)
at com.intellij.openapi.externalSystem.service.execution.ForkedDebuggerThread.run(ForkedDebuggerThread.java:103)
I've done quite a bit of searching through SO here, and have found several people that had similar problems. Most of them were resolve simply by upgrading (to 2013 or whatever, these questions aren't exactly spring chickens). The rest required some special sauce relevant to their system (android stuff mostly). Or they're getting a different exception (being disconnected, where I'm never getting the connection in the first place).
These tests (unit tests for the most part) are attached to a module with no "main".
I've tried launching gradlew -DtestDebug.test=true cleanTest test, and then connect with a remote debug session. I get an error: Unable to open debugger port (localhost:5005); java.net.ConnectException "Connection refused: connect", which I believe is just what IntelliJ's gui shows when it receives the aforementioned exception.
Ideally, I'd like to set my breakpoints, debug-launch my test task (perhaps specifying a class or individual #Test), and it'd Just Work.
Does anyone have any other ideas I could try? Logs I could look at?
The workaround is to switch the build/run actions to IntelliJ IDEA instead of using Gradle.
But if you still have this issue in the current IDE version, please consider reporting it with the sample project and the logs (Help | Compress Logs and Show in ...) attached.

Reason and fix for "Error: Could not find or load main class Anne" on Scala Getting started tutorial

I'm just starting out with Scala and have been following its Getting Started instructions. The second part of the instruction involves pulling the hello-world template by running the sbt new scala/hello-world.g8 command.
My problem is that it keeps on giving me this error:
Error: Could not find or load main class Anne
Caused by: java.lang.ClassNotFoundException: Anne
I'd like to know the reason for this, as well as any possible fix I might use.
The following is my insight and attempts on fixing this problem.
Insight:
1. I might have a problem with java installation/scala/sbt installation that needs this class Anne since even with other sbt commands like sbt sbtVersion I get the same error
Attempts:
1. Change command to retrieve from full url:
sbt new https://github.com/scala/hello-world.g8
2.(Edit): Previously I thought the repository scala/hello-world.g8 did not exist and tried getting from other repositories with no luck and with the same error as above. However it was pointed out below that the repository actually exists in this url https://github.com/scala/hello-world.g8, thanks Dmytro Mitin.
I was looking into the incorrect account (sbt) instead of (scala)
(Edit): Day 2
3. Uninstall/Reinstall sbt -- still getting the error
4. Checked if java running properly by compiling sample code and running ( successful )
I was actually running the command in Visual Studio Code's bash terminal. I tried running it with cmd and everything's now working fine.

After upgrading to new Jenkins version, builds are failing

I just upgraded the jenkins from 2.63 to 2.117 (Which I'm regretting now)
Here is the error message I'm getting at the end of all the jobs.
Please help me to understand and resolve this.
FATAL: java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class hudson.model.FreeStyleBuild
java.lang.UnsupportedOperationException: Refusing to marshal java.io.PrintStream for security reasons; see https://jenkins.io/redirect/class-filter/
at hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
Caused: java.lang.RuntimeException: Failed to serialize org.jenkinsci.plugins.EnvironmentVarSetter#log for class org.jenkinsci.plugins.EnvironmentVarSetter
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:256)
at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:224)
at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:138)
at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:209)
at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:150)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
at com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
Caused: java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class hudson.model.FreeStyleBuild
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:256)
at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:224)
at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:138)
at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:209)
at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:150)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:82)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:1026)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:1015)
at com.thoughtworks.xstream.XStream.toXML(XStream.java:988)
at hudson.XmlFile.write(XmlFile.java:193)
Caused: java.io.IOException
at hudson.XmlFile.write(XmlFile.java:200)
at hudson.model.Run.save(Run.java:1923)
at hudson.model.Run.setDisplayName(Run.java:803)
at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.setDisplayName(BuildNameSetter.java:76)
at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.access$000(BuildNameSetter.java:31)
at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter$1.tearDown(BuildNameSetter.java:64)
at hudson.model.Build$BuildExecution.doRun(Build.java:174)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
at hudson.model.Run.execute(Run.java:1727)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Note: Others who are using older version of jenkins, there is a big chance that all your jobs will be messed up. So, Please do not update jenkins as of now. (https://jenkins.io/blog/2018/03/15/jep-200-lts/)
You can try the solution given in the official site of Jenkins
https://issues.jenkins-ci.org/browse/JENKINS-49144
Add the three following entries to whitelisted-classes.txt:
java.util.concurrent.locks.ReentrantLock
java.util.concurrent.locks.ReentrantLock$NonfairSync
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
It is to do with the two things.
Permission to be updated to the .war file.
Build Pipeline plugin needs to be updated.
This solved my problem.
It's a known security fix in Jenkins https://github.com/jenkinsci/jep/tree/master/jep/200.
You can check list of affected plugins https://wiki.jenkins.io/display/JENKINS/Plugins+affected+by+fix+for+JEP-200 and upgrade your affected ones to overcome the error.

Can not run program, permission denied erro13 Jenkins

I created a new job for android new project on Jenkin. Whenever I run the job I got error java.io.ioexception error 13 permission denied. Jenkin says unable to run program gradlew. I know gradlew script need execution permissions according to the error explanation . I granted these and re run the jenkin job. I still get the same error. Jenkin revert the execution permission back after build. When I create new job from existing job and configured with old projects repository , it runs fine. when I configured with new project repository it raised permission issues. I played a lot with permission but no success. I also compared old and new project script file. There was few lines difference but it shouldn't be an issue. Any one can guide me what I am doing wrong.
Thanks
It is clearly a permission issue.
java.io.IOException: Cannot run program "<http://jenkins.gradlew"
error=13, Permission denied
Caused by: java.io.IOException: error=13, Permission denied
There are two solutions to resolve the gradlew permission issue.
Go to Jenkin Job configuration
Go to Build tab and check gradlew executable.
Jenkin will change the permission when you press build now. Keep in mind that these changes are uncommitted. The process works fine if your job is not a release job. If it is release job it creates another issue that I came across.
:workspace:app:checkCommitNeeded FAILED
:app:release FAILED
* What went wrong:
Execution failed for task ':workspace:app:checkCommitNeeded'.
> You have uncommitted files:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M gradlew
So work around is
commit gradlew with executable bit set:
git update-index --chmod=+x gradlew
git commit
Then you will no longer need the jenkins setting to set it executable, which is the workaround causing the 2nd issue.
Hopefully it would save someone time because I spent hours for the work around.
I was using Github for source code management. It was fetching code there and was updating it every single time, so changing it to +x before submitting my Jenkins job didn't help.
In Linux the project is at /.jenkins/workspace/MyProjectName/SomeSubFolder/gradlew - and it was loosing +x evereytime a new job was submitted (to 644, I think).
The solution was to select the Make gradlew executable checkbox (in Build --> Use Gradle Wrapper) - it is 755 now, and is executing gradle tasks.
Are you using a jenkinsfile for your job configuration?
If so you need to add the permission change for gradlew there.
sh 'chmod 755 ./gradlew'
It sounds like your gradlew is being replaced each time with a version that doesn't have the execute permission set so you will need to do it as part of the jenkins job either via a script or the jenkinsfile.

Categories