SonarLint for Eclipse 2022-03 hangs

  • Operating system: Both Linux and Windows
  • IDE name and flavor/env: Eclipse + JDT 2022-03
  • SonarLint plugin version: 7.3.1.45470
  • Is connected mode used:
    • Connected to SonarCloud or SonarQube (and which version): SonarQube Version 9.4 (build 54424)

About once a day our SonarLint hangs. In Eclipse’s progress view we can see that it’s trying to analyze a file (which usually only takes a few seconds) for hours on ends. When this happens, multiple files are stuck in sonar’s queue.

Note that we also use Annotation Processing for use with AutoValue.

Please let us know how we can help you debug and fix this issue.

Hi @tivervac

What would help us to understand the issue is to take a thread dump when SonarLint hangs. There are many different ways to capture, I let you read this page.

Thanks!

Hi @Julien_HENRY

Since Eclipse 2021-12 (and likely the sonarlint release that went along with it), we’ve been suffering from our auto-generated AutoValue classes randomly receiving errors when we’re editing code near (but not in) the auto value. We have a feeling this SonarLint hang and the broken AutoValue is related. Without further ado, here’s the output of jstack -l <pid> and jstack <pid> during the hang.

jstack-l-pid.txt (329.2 KB)
jstack-pid.txt (309.0 KB)

You can also see that the sonarlint hanging is causing a memory leak in the following image.

Hi @tivervac

This is very useful, thanks!

It seems SonarLint is stuck while trying to sync connected mode local storage:

"Worker-18: Synchronize quality profiles with SonarQube/SonarCloud" #108 prio=5 os_prio=0 cpu=36477.84ms elapsed=8480.35s tid=0x00007f94b4034800 nid=0x347e waiting on condition  [0x00007f93d84ed000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@11.0.12/Native Method)
	- parking to wait for  <0x0000000769c38200> (a java.util.concurrent.CompletableFuture$Signaller)
	at java.util.concurrent.locks.LockSupport.park(java.base@11.0.12/LockSupport.java:194)
	at java.util.concurrent.CompletableFuture$Signaller.block(java.base@11.0.12/CompletableFuture.java:1796)
	at java.util.concurrent.ForkJoinPool.managedBlock(java.base@11.0.12/ForkJoinPool.java:3128)
	at java.util.concurrent.CompletableFuture.waitingGet(java.base@11.0.12/CompletableFuture.java:1823)
	at java.util.concurrent.CompletableFuture.get(java.base@11.0.12/CompletableFuture.java:1998)
	at org.sonarsource.sonarlint.core.serverapi.system.SystemApi.getStatusSync(SystemApi.java:53)
	at org.sonarsource.sonarlint.core.storage.LocalStorageSynchronizer.synchronize(LocalStorageSynchronizer.java:50)
	at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.sync(ConnectedSonarLintEngineImpl.java:368)
	at org.sonarlint.eclipse.core.internal.engine.connected.ConnectedEngineFacade.lambda$35(ConnectedEngineFacade.java:656)
	at org.sonarlint.eclipse.core.internal.engine.connected.ConnectedEngineFacade$$Lambda$1180/0x0000000801147840.accept(Unknown Source)
	at org.sonarlint.eclipse.core.internal.engine.connected.ConnectedEngineFacade.doWithEngine(ConnectedEngineFacade.java:210)
	- locked <0x00000007491a1698> (a org.sonarlint.eclipse.core.internal.engine.connected.ConnectedEngineFacade)
	at org.sonarlint.eclipse.core.internal.engine.connected.ConnectedEngineFacade.sync(ConnectedEngineFacade.java:655)
	at org.sonarlint.eclipse.core.internal.engine.connected.ConnectedEngineFacade.syncAllProjects(ConnectedEngineFacade.java:665)
	at org.sonarlint.eclipse.ui.internal.job.QualityProfilesSynchronizerJob.run(QualityProfilesSynchronizerJob.java:58)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

We can see that http requests are stuck:

"OkHttp https://sonarqube.sigasi.com/..." #16747 prio=5 os_prio=0 cpu=8.23ms elapsed=259.35s tid=0x00007f95a876b800 nid=0x3ae5 in Object.wait()  [0x00007f92863ea000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(java.base@11.0.12/Native Method)
	- waiting on <no object reference available>
	at java.lang.Object.wait(java.base@11.0.12/Object.java:328)
	at okhttp3.internal.http2.Http2Stream.waitForIo(Http2Stream.java:660)
	at okhttp3.internal.http2.Http2Stream.takeHeaders(Http2Stream.java:151)
	- waiting to re-lock in wait() <0x0000000769cabde0> (a okhttp3.internal.http2.Http2Stream)
	at okhttp3.internal.http2.Http2ExchangeCodec.readResponseHeaders(Http2ExchangeCodec.java:136)
	at okhttp3.internal.connection.Exchange.readResponseHeaders(Exchange.java:115)
	at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:94)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
	at org.sonarlint.eclipse.core.internal.http.PreemptiveAuthenticatorInterceptor.intercept(PreemptiveAuthenticatorInterceptor.java:40)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
	at org.sonarlint.eclipse.core.internal.http.UserAgentInterceptor.intercept(UserAgentInterceptor.java:43)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:43)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:94)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:88)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:229)
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:172)
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.12/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.12/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(java.base@11.0.12/Thread.java:829)

This could be an issue in the httpclient library we are using (okhttp). For example I found this old issue report.

This might be due to something special in your network. Do you have any kind of proxy between you and your SonarQube server?

One the other hand, the fact that the “sync” is stuck in the background should not block SonarLint. We should be able to continue analyzing code with the previous version of the local storage. I have created a ticket to fix that, but I would really like to understand the original problem (= why is the sync process stuck) because this could remain a problem if SonarLint is not able to synchronize with SonarQube.

I prepared a custom build of SonarLint for Eclipse, with HTTP/2 disabled. Can you give a try and let me know if this is improving the situation?
https://repox.jfrog.io/repox/sonarsource/org/sonarsource/sonarlint/eclipse/org.sonarlint.eclipse.site/7.5.0.47642/org.sonarlint.eclipse.site-7.5.0.47642.zip

Thanks

We’ve installed your build, we’ll let you know in a few days whether this works better. Our network and computers don’t do anything special. The request should go through without issue. We’ve also always been able to update our bindings easily in the past.

@Julien_HENRY A few people at Sigasi have tried out your build. With that build everything works perfectly. What are the next steps here?