sbt stuck on windows 10 command prompt #5128
Labels
area/library_management
library management
area/proxy_network
area/windows
Windows-specific issue
Bug
Needs Reproduction Test Case
workaround exists
There's a workaround
Comments
|
Does it happen on all projects? |
eed3si9n
added
Needs Reproduction Test Case
area/windows
|
Hi, sorry for the late reply. It does seem to happen on all projects - from Play projects to empty directory that I use for I have deleted the plugins (in Some updates: Running IntelliJ on 1.3.2 does not work. Reverting back to 1.2.8 solves the problem - both when using from command prompt and from IntelliJ. All testing done on JDK11. FWIW I am using a 6 years-old computer (W10) running on HDD so it's not the most performant computer. |
|
This occurs on my machine as well. Windows 7 64-bit. Same problem exactly (including the error message when aborting). SBT 1.2.8 works, but 1.3.x gets stuck. |
|
This is the dump file when I run sbt 1.3.5 with just a build.properties file: |
|
This looks a bug in coursier. Could you report it there as well, please? |
|
Maybe this bug was already resolved? coursier/coursier#1387 |
|
Any news on this? I'm stuck. Can't upgrade to 1.3.x because of this bug, and cannot publish in 1.2.8 due to a protobuf bug that was supposedly already resolved in 1.3.x |
|
@soronpo There was a change to directories-jvm dirs-dev/directories-jvm#27, which was about it returning a directory named "null" in the current working directory, but it highlighted the issue of Coursier shelling out to powershell to calculate the default cache directory. There's some possibility that #5354 might fix this, but otherwise I'd suggest you define I suggested that we use the same directory for all OSes here coursier/coursier#1483, but it doesn't seem to be a popular suggestion. workaroundDefine |
|
For the record sbt 1.3.6 uses lm-coursier-shaded 2.0.0-RC5-2, which uses Coursier 2.0.0-RC5-2, which uses some version of directories-jvm https://github.com/coursier/coursier/tree/v2.0.0-RC5-2/modules. |
eed3si9n
added
area/library_management
|
@soronpo For the actual fix, I suggest you open an issue on https://github.com/soc/directories-jvm/ |
|
@eed3si9n it seems the coursier issue just hide the true problem.
I did it, and now it's stuck around a plugin-update |
|
I tried a completely empty new project (environment variable for coursier is set): |
|
This is the jstack dump: |
|
The stack trace still showing https://github.com/soc/directories-jvm/ as far as I can tell: at java.io.FileInputStream.readBytes(java.base@11.0.5/Native Method)
at java.io.FileInputStream.read(java.base@11.0.5/FileInputStream.java:279)
at java.io.BufferedInputStream.read1(java.base@11.0.5/BufferedInputStream.java:290)
at java.io.BufferedInputStream.read(java.base@11.0.5/BufferedInputStream.java:351)
- locked <0x1b3079d8> (a java.io.BufferedInputStream)
at sun.nio.cs.StreamDecoder.readBytes(java.base@11.0.5/StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(java.base@11.0.5/StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(java.base@11.0.5/StreamDecoder.java:178)
- locked <0x1b309c00> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(java.base@11.0.5/InputStreamReader.java:185)
at java.io.BufferedReader.fill(java.base@11.0.5/BufferedReader.java:161)
at java.io.BufferedReader.readLine(java.base@11.0.5/BufferedReader.java:326)
- locked <0x1b309c00> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(java.base@11.0.5/BufferedReader.java:392)
at lmcoursier.internal.shaded.coursier.cache.shaded.io.github.soc.directories.Util.runCommands(Util.java:160)
at lmcoursier.internal.shaded.coursier.cache.shaded.io.github.soc.directories.Util.getWinDirs(Util.java:122)
at lmcoursier.internal.shaded.coursier.cache.shaded.io.github.soc.directories.ProjectDirectories.fromPath(ProjectDirectories.java:221)
at lmcoursier.internal.shaded.coursier.cache.shaded.io.github.soc.directories.ProjectDirectories.from(ProjectDirectories.java:274)I'm closing this for now. |
|
Still reproducible in sbt We face this issue in Scala Plugin during sbt project import tests on Windows CI agents. /**
* This is a workaround for [[https://github.com/sbt/sbt/issues/5128]] (tested for sbt 1.4.9)
*
* The bug is reproduced on Teamcity, on Windows agents:
* ProjectImportingTest is stuck indefinitely when the test is run from sbt.<br>
* It's also reproduces locally when running the test from sbt.<br>
* But for some reason is not reproduced when running from IDEA test runners<br>
*
* Environment variables which have to be mocked are inferred from methods in
* `lmcoursier.internal.shaded.coursier.paths.CoursierPaths` (version 2.0.6)
*
* @see [[https://github.com/sbt/sbt/issues/5128]]
* @see [[https://github.com/dirs-dev/directories-jvm/issues/49]]
* @see [[https://github.com/ScoopInstaller/Main/pull/878/files]]
*/
private def defaultCoursierDirectoriesAsEnvVariables(): Seq[(String, String)] = {
val LocalAppData = System.getenv("LOCALAPPDATA")
val AppData = System.getenv("APPDATA")
val CoursierLocalAppDataHome = LocalAppData + "/Coursier"
val CoursierAppDataHome = AppData + "/Coursier"
Seq(
// these 2 variables seems to be enough for the workaround
("COURSIER_CACHE", CoursierLocalAppDataHome + "/cache/v1"),
("COURSIER_CONFIG_DIR", CoursierAppDataHome + "/config"),
// these 2 variables seems to be optional, but we set them just in cause
// they might be accessed in some unpredictable cases
("COURSIER_JVM_CACHE", CoursierLocalAppDataHome + "/cache/jvm"),
("COURSIER_DATA_DIR", CoursierLocalAppDataHome + "/data"),
// this also looks like an optional in 1.4.9, but setting it just in case
("COURSIER_HOME", CoursierLocalAppDataHome),
)
}@eed3si9n I suppose you could update the comment with a workaround and mention you need to set
These ^ 2 paths were enough to make it work in our case, but you might set these as well just in case:
|
unkarjedy
added a commit
to JetBrains/intellij-scala
that referenced
this issue
Apr 19, 2021
… unit tests on windows to avoid hanging ProjectImportTest This is required to workaround sbt/sbt#5128; The bug is reproduced on Teamcity, on Windows agents. ProjectImportingTest is stuck indefinitely when the test is run from sbt. It's also reproduces locally when running the test from sbt. But for some reason is not reproduced when running from IDEA test runners. Environment variables which have to be mocked are inferred from - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeCacheDirectory - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeJvmCacheDirectory see also dirs-dev/directories-jvm#49 see also https://github.com/ScoopInstaller/Main/pull/878/files
unkarjedy
added a commit
to JetBrains/intellij-scala
that referenced
this issue
Apr 19, 2021
… unit tests on windows to avoid hanging ProjectImportTest This is required to workaround sbt/sbt#5128; The bug is reproduced on Teamcity, on Windows agents. ProjectImportingTest is stuck indefinitely when the test is run from sbt. It's also reproduces locally when running the test from sbt. But for some reason is not reproduced when running from IDEA test runners. Environment variables which have to be mocked are inferred from - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeCacheDirectory - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeJvmCacheDirectory see also dirs-dev/directories-jvm#49 see also https://github.com/ScoopInstaller/Main/pull/878/files
unkarjedy
added a commit
to JetBrains/intellij-scala
that referenced
this issue
Apr 22, 2021
… unit tests on windows to avoid hanging ProjectImportTest This is required to workaround sbt/sbt#5128; The bug is reproduced on Teamcity, on Windows agents. ProjectImportingTest is stuck indefinitely when the test is run from sbt. It's also reproduces locally when running the test from sbt. But for some reason is not reproduced when running from IDEA test runners. Environment variables which have to be mocked are inferred from - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeCacheDirectory - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeJvmCacheDirectory see also dirs-dev/directories-jvm#49 see also https://github.com/ScoopInstaller/Main/pull/878/files
unkarjedy
added a commit
to JetBrains/intellij-scala
that referenced
this issue
Apr 23, 2021
… unit tests on windows to avoid hanging ProjectImportTest This is required to workaround sbt/sbt#5128; The bug is reproduced on Teamcity, on Windows agents. ProjectImportingTest is stuck indefinitely when the test is run from sbt. It's also reproduces locally when running the test from sbt. But for some reason is not reproduced when running from IDEA test runners. Environment variables which have to be mocked are inferred from - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeCacheDirectory - lmcoursier.internal.shaded.coursier.paths.CoursierPaths.computeJvmCacheDirectory see also dirs-dev/directories-jvm#49 see also https://github.com/ScoopInstaller/Main/pull/878/files
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
steps
sbt version: 1.2.8, 1.3.0, 1.3.2,
java 11
windows 10 cmd
Install sbt through the windows installer (.msi file).
Type sbt in command prompt.
sbt does not proceed past this step:
[info] Loading settings for project global-plugins from idea.sbt ...problem
sbt does not proceed past:
[info] Loading settings for project global-plugins from idea.sbt ...I didn't wait past 15 minutes. I had to ctrl+c to kill it. At which point it says:
expectation
sbt should work.
notes
I noticed it's waiting for idea.sbt. Could this be an issue related to intellij? I have intelliJ community installed. I could not find any information regarding this file on the internet.
I upgraded to 1.3.2 and faced this issue, downgraded to 1.3.0 and 1.2.8 and still faced the same issue.
Previously I had 1.2.8 working perfectly on intellij, though I suspect it would have the same problem if I were to run from cmd.
I have not tested sbt 1.3.2 on Intellij. I presume it should work fine (since there were no github issues). This is only for cmd.
The text was updated successfully, but these errors were encountered: