Sqldelight: Android Studio crashing after updating to 1.4.2

[eygraber]

Build Environment
SQLDelight version: 1.4.2
IDE version: Android Studio 4.0.1
Dialect: SQLite

I haven't looked too much into it, but after updating the SqlDelight plugin to 1.4.2, Android Studio randomly started crashing (and taking a good chunk of my OS with it). I tried using Android Studio 4.1.0 RC 1 and it still happened. After downgrading the plugin to 1.3.0 the crash stopped happening.

Android Studio 4.0.1
Build #AI-193.6911.18.40.6626763, built on June 24, 2020
Runtime version: 1.8.0_242-release-1644-b3-6222593 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 5.7.1-050701-generic
GC: ParNew, ConcurrentMarkSweep
Memory: 4012M
Cores: 12
Registry: ide.new.welcome.screen.force=true, debugger.watches.in.variables=false, debugger.showTypes=false
Non-Bundled Plugins: Key Promoter X, org.jetbrains.kotlin, com.developerphil.adbidea, com.squareup.sqldelight, detekt

[JakeWharton]

Can you find the stacktrace in the idea.log?

[eygraber]

I just tried with 1.4.2 again and paid attention. It actually looks more like a memory leak, because all of my Chrome tabs, slack, etc... got killed.

I can consistently repro by performing a "Go to Declaration or Usages" action, and watch 10s of GBs of memory suddenly get used.

[eygraber]

Attaching a thread dump from while this is happening

dump.txt

[BenTilbrook]

I also started getting this issue after updating the plugin. It appears to spawn hundreds of java processes upon using find usages.

[minyushov]

I'm getting the same issue after updating to 1.4.2. Attaching a thread dump.

There are a lot of waiting threads with SqlDelightGotoDeclarationHandler:

"ApplicationImpl pooled thread 4" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@3b0a8c12
    at [email protected]/jdk.internal.misc.Unsafe.park(Native Method)
    at [email protected]/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
    at [email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
    at [email protected]/java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:417)
    at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:40)
    at org.gradle.tooling.internal.consumer.DefaultModelBuilder.get(DefaultModelBuilder.java:51)
    at org.gradle.tooling.internal.consumer.DefaultProjectConnection.getModel(DefaultProjectConnection.java:57)
    at com.squareup.sqldelight.intellij.ProjectService.fileIndex(ProjectService.kt:80)
    at com.squareup.sqldelight.core.SqlDelightFileIndex$Companion.getInstance(SqlDelightFileIndex.kt:75)
    at com.squareup.sqldelight.intellij.SqlDelightGotoDeclarationHandler.getGotoDeclarationTargets(SqlDelightGotoDeclarationHandler.kt:54)
    at com.intellij.codeInsight.navigation.action.GotoDeclarationUtil.findTargetElementsFromProviders(GotoDeclarationUtil.java:27)
    at com.intellij.codeInsight.navigation.impl.GtdProvidersKt.fromGTDProvidersInner(gtdProviders.kt:31)
    ...

[AlecStrong]

Interesting, I guess the gradle tooling API starts a daemon per project, not per connector. Will have to be smart about joining an existing connection then. Did you also upgrade the gradle plugin, or just the IDE?

Also did this happen while performing a goTo/find usages? Or just while the IDE is running normally?

Will look into this soon, probably worth downgrading if it’s still causing issues

[eygraber]

I just updated the IDE plugin (still blocked on https://github.com/cashapp/sqldelight/issues/1809).

I've tested a bunch, and it seems to only happen when doing a go to / find usages.

[bogdanzurac]

Can confirm this happens as well when trying a goTo/FindUsages on AS & gradle plugin v4.0.1.

[jameswald]

It happens when deleting code too. Larger blocks of code tend to trigger the hangs. On both of my macs this hang lasts for anywhere from 5 seconds to 3 minutes, median around 60 seconds. I see the same issue in my thread dumps and many java processes spawning while the rest of the OS hangs. Looks like you may have enough evidence above but I can provide additional logs if it would help.

[LouisCAD]

Is SqlDelight launching Gradle daemons directly or indirectly?

[LouisCAD]

Referencing this issue that includes a screenshot, thread dumps and a snapshot of the jps command that shows many GradleDaemon processes being launched from an unknown place (likely in the SqlDelight plugin) while the freeze is ongoing: https://issuetracker.google.com/issues/167259199

[AlecStrong]

We're using the gradle tooling API which spawns daemons. If the IDE hasn't been configured yet it'll spawn a new one per project, but this isn't thread safe in the current version so I think a crapton get spawned since there are multiple requesters in the case of a GoTo/FindUsages, and then it blows up/grinds to a halt. 100% the issue you linked @LouisCAD is SQLDelight

I've got a branch going which fixes some pieces I was able to reproduce locally. Give this snapshot a try:

SQLDelight-1.5.0-SNAPSHOT.zip

It does a few things:

1. Limit # of daemons to one per project
2. Add a timeout for getting a model from the daemon
3. Adds debug logging to the IDE plugin

If it's still causing issues, can you attach the idea.log file here and that'll help narrow down specific issues. You can get the log file from the Help menu in AS/IntelliJ

[AlecStrong]

I'm seeing if there's a way to have it use a gradle daemon for the root project instead of individual projects, since starting up 100 daemons for 100 modules is dumb and ideally if its the root project we can just reuse an already running daemon

[LouisCAD]

@AlecStrong I had the issue occur when opening a project that is not using SqlDelight. Is there a way to do almost nothing when the project is not using SqlDelight? Gradle daemons can be expensive and taxing to already loaded machines.

[AlecStrong]

they shouldn't be persistent, the daemon is just a side effect of the tooling API but once we find out if it is configured with SQLDelight the daemon should be getting killed. regardless, we need to communicate with gradle to know if the project is using sqldelight

[LouisCAD]

@AlecStrong Can't this be cached and refreshed opportunistically when a Gradle import/sync happens in the IDE?

[AlecStrong]

yea the result gets cached, the issue was it not being thread safe and so 20 threads seeing an empty cache and all loading up a daemon for themselves. the snapshot above should fix that issue

[LouisCAD]

Is it cached in memory or also in ~disk~ storage?

[jameswald]

Thanks for the rapid fix @AlecStrong!

[AlecStrong]

if anyone runs into this before the next proper release you can download the snapshot plugin off our eap channel

[LouisCAD]

Given how critical this issue is, doesn't it justify a quick 1.4.3 update on the stable channel to avoid more people being affected?

[LouisCAD]

Thank you very much for the release with the fix, Alec!
And of course, thanks to you and all the collaborators and contributors for SqlDelight.