You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using Jdtls in neovim with vscode-java-test and java-debug module. After upgrading from v1.3x.x, starting jdtls has been significantly slower sometimes. The log shows that there're deadlock problem.
This problem don't occurs in relativley small projects. I haven't tried other types of projects, but there's problem with spring boot project.
Here's log and build.gralde file.
Log
!SESSION 2024-11-29 14:06:59.983 -----------------------------------------------
eclipse.buildId=unknown
java.version=17.0.10
java.vendor=Eclipse Adoptium
BootLoader constants: OS=macosx, ARCH=aarch64, WS=cocoa, NL=ko_KR
Command-line arguments: -data /Users/dogchew/.cache/nvim/jdtls/workspace/tech-blog
This is a continuation of log file /Users/dogchew/.cache/nvim/jdtls/workspace/tech-blog/.metadata/.bak_0.log
Created Time: 2024-11-29 14:10:02.661
!ENTRY org.eclipse.osgi 2 0 2024-11-29 14:10:02.661
!MESSAGE While loading class "org.eclipse.buildship.core.WrapperGradleDistribution", thread "Thread[Worker-4: Initialize Workspace,5,main]" timed out waiting (30034ms) for thread "Thread[Worker-1: Initialize After Load,5,main]" to finish starting bundle "org.eclipse.buildship.core_3.1.10.v20240802-0834-s [200]". To avoid deadlock, thread "Thread[Worker-4: Initialize Workspace,5,main]" is proceeding but "org.eclipse.buildship.core.WrapperGradleDistribution" may not be fully initialized.
!STACK 0
org.osgi.framework.BundleException: Unable to acquire the state change lock for the module: osgi.identity; type="osgi.bundle"; version:Version="3.1.10.v20240802-0834-s"; osgi.identity="org.eclipse.buildship.core"; singleton:="true" [id=200] STARTED [STARTED]
at org.eclipse.osgi.container.Module.lockStateChange(Module.java:373)
at org.eclipse.osgi.container.Module.start(Module.java:447)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:528)
at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:122)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:620)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:348)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:414)
at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:41)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass0(BundleLoader.java:516)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:434)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:174)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3373)
at java.base/java.lang.Class.getConstructor0(Class.java:3578)
at java.base/java.lang.Class.getDeclaredConstructor(Class.java:2754)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:233)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:987)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:275)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:65)
at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.importers(ProjectsManager.java:401)
at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.importProjects(ProjectsManager.java:161)
at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.initializeProjects(ProjectsManager.java:126)
at org.eclipse.jdt.ls.core.internal.handlers.InitHandler$1.runInWorkspace(InitHandler.java:277)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:43)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.util.concurrent.TimeoutException: Timeout after waiting 30 seconds to acquire the lock.
at org.eclipse.osgi.container.Module.lockStateChange(Module.java:368)
... 25 more
Caused by: org.eclipse.osgi.framework.util.ThreadInfoReport: Thread dump
ThreadId: 1 ThreadName: main ThreadState: WAITING
Blocked On: java.lang.Object@78d94588 LockOwnerId: -1 LockOwnerName: null
Synchronizers Locked: none
Monitors Locked: none
Stack Trace:
[email protected]/java.lang.Object.wait(Native Method)
[email protected]/java.lang.Object.wait(Object.java:338)
org.eclipse.jdt.ls.core.internal.LanguageServerApplication.start(LanguageServerApplication.java:63)
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:208)
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:143)
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:109)
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:439)
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:271)
[email protected]/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[email protected]/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[email protected]/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[email protected]/java.lang.reflect.Method.invoke(Method.java:568)
app//org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:668)
app//org.eclipse.equinox.launcher.Main.basicRun(Main.java:605)
app//org.eclipse.equinox.launcher.Main.run(Main.java:1481)
app//org.eclipse.equinox.launcher.Main.main(Main.java:1454)
ThreadId: 2 ThreadName: Reference Handler ThreadState: RUNNABLE
Blocked On: none
Synchronizers Locked: none
Monitors Locked: none
Stack Trace:
[email protected]/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
[email protected]/java.lang.ref.Reference.processPendingReferences(Reference.java:253)
[email protected]/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:215)
...
I'm using Jdtls in neovim with vscode-java-test and java-debug module. After upgrading from v1.3x.x, starting jdtls has been significantly slower sometimes. The log shows that there're deadlock problem.
This problem don't occurs in relativley small projects. I haven't tried other types of projects, but there's problem with spring boot project.
Here's log and build.gralde file.
Log
build.gradle
The text was updated successfully, but these errors were encountered: