FATAL: bazel crashed due to an internal error: UnsatisfiedLinkError nativeIsSymlinkOrJunction #20677
Labels
area-Windows
Windows-specific issues and feature requests
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
type: bug
untriaged
Comments
sgowroji
added
the
team-OSS
|
I couldn't reproduce this issue on a Windows VM. Anything else useful for debugging? Does it still happen with |
|
I tried setting As I mentioned earlier, we do have a script that runs What would cause this error though? I'm guessing Bazel needs to extract its JNI DLL and then fails to load that, but why might that happen? Here's the output from |
|
The DLL where the Is there anything in the server log ( |
|
Thanks @tjgq, I didn't know where to look for the server log. The root cause is that our CI script deletes not only the contents of 240102 18:51:06.927:WT 1 [com.google.devtools.build.lib.jni.JniLoader.*** Failed to load JNI library from resource java.nio.file.NoSuchFileException: C:\Users\ADMINI~1\AppData\Local\Temp\bazel-jni.15087218107965058839 at java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at java.base/sun.nio.fs.WindowsFileSystemProvider.createDirectory(Unknown Source) at java.base/java.nio.file.Files.createDirectory(Unknown Source) at java.base/java.nio.file.TempFileHelper.create(Unknown Source) at java.base/java.nio.file.TempFileHelper.createTempDirectory(Unknown Source) at java.base/java.nio.file.Files.createTempDirectory(Unknown Source) at com.google.devtools.build.lib.jni.JniLoader.loadLibrary(JniLoader.java:91) at com.google.devtools.build.lib.jni.JniLoader.(JniLoader.java:60) at com.google.devtools.build.lib.platform.SystemSuspensionModule.(SystemSuspensionModule.java:30) at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method) at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unknown Source) at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(Unknown Source) at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newConstructorAccessor(Unknown Source) at java.base/jdk.internal.reflect.ReflectionFactory.newConstructorAccessor(Unknown Source) at java.base/java.lang.reflect.Constructor.acquireConstructorAccessor(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) at com.google.devtools.build.lib.runtime.BlazeRuntime.createModules(BlazeRuntime.java:[78](https://github.com/EngFlow/engflow/actions/runs/7389414975/job/20102203579#step:3:78)5) at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:761) at com.google.devtools.build.lib.bazel.Bazel.main(Bazel.java:[95](https://github.com/EngFlow/engflow/actions/runs/7389414975/job/20102203579#step:3:95)) It's reasonable for Bazel to assume the temp directory exists and crash if it doesn't, so perhaps this issue can be closed without action. However, I'd love a more helpful error message. If the server crashes on startup for whatever reason, it would be great for the client to print that log or tell the user where to find it. |
|
Yes, we should have failed earlier with the more informative error message (and not expect users to go look for it in the log). I have a pending change to do so. |
copybara-service bot
pushed a commit
to bazelbuild/intellij
that referenced
this issue
Jan 2, 2024
Unlike on Unix, we can't fall back to an alternative implementation. Failure to emit an early error would cause later native method calls to produce a less informative error message. See bazelbuild/bazel#20677 for a recent example where this would have been helpful. Also note some minor changes: * Since we attempt to load the JNI in two different ways, make sure to propagate both exceptions (one suppressed by the other). * The default switch case is unnecessary, as errorprone already enforces exhaustiveness. PiperOrigin-RevId: 595206761
copybara-service bot
pushed a commit
that referenced
this issue
Jan 2, 2024
Unlike on Unix, we can't fall back to an alternative implementation. Failure to emit an early error would cause later native method calls to produce a less informative error message. See #20677 for a recent example where this would have been helpful. Also note some minor changes: * Since we attempt to load the JNI in two different ways, make sure to propagate both exceptions (one suppressed by the other). * The default switch case is unnecessary, as errorprone already enforces exhaustiveness. PiperOrigin-RevId: 595206761 Change-Id: I4b6258d59d9a4fcc9f83418375acc51a32d7f4a4
See 2d93597. |
mai93
pushed a commit
to bazelbuild/intellij
that referenced
this issue
Jan 15, 2024
Unlike on Unix, we can't fall back to an alternative implementation. Failure to emit an early error would cause later native method calls to produce a less informative error message. See bazelbuild/bazel#20677 for a recent example where this would have been helpful. Also note some minor changes: * Since we attempt to load the JNI in two different ways, make sure to propagate both exceptions (one suppressed by the other). * The default switch case is unnecessary, as errorprone already enforces exhaustiveness. (cherry picked from commit e95d1ee)
tjgq
added a commit
to tjgq/bazel
that referenced
this issue
Jan 26, 2024
…error. Unlike on Unix, we can't fall back to an alternative implementation. Failure to emit an early error would cause later native method calls to produce a less informative error message. See bazelbuild#20677 for a recent example where this would have been helpful. Also note some minor changes: * Since we attempt to load the JNI in two different ways, make sure to propagate both exceptions (one suppressed by the other). * The default switch case is unnecessary, as errorprone already enforces exhaustiveness. PiperOrigin-RevId: 595206761 Change-Id: I4b6258d59d9a4fcc9f83418375acc51a32d7f4a4
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 27, 2024
…error. (#21090) Unlike on Unix, we can't fall back to an alternative implementation. Failure to emit an early error would cause later native method calls to produce a less informative error message. See #20677 for a recent example where this would have been helpful. Also note some minor changes: * Since we attempt to load the JNI in two different ways, make sure to propagate both exceptions (one suppressed by the other). * The default switch case is unnecessary, as errorprone already enforces exhaustiveness. PiperOrigin-RevId: 595206761 Change-Id: I4b6258d59d9a4fcc9f83418375acc51a32d7f4a4
|
FWIW, I had a very similar issue. I had the following error message pop up: Upon following @tjgq's instructions of opening the server log, I found the root cause to be: Should we treat the failure to load |
|
Which Bazel version did you use? This specific error should be fixed by 388f687 where it checks whether the JNI was successfully loaded before calling into native methods. |
|
I was using last_green from a few days ago. I can confirm that when I sync to head your fix appears to work for my specific issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the bug:
When running
bazel --output_user_root=C:\_b clean --expungein our Windows CI environment, we get the following error.Oddly, our regular
bazel testcommand succeeds, when run immediately after. The only difference in configuration I can think of is that thebazel testcommand is invoked with--nosystem_rc. Our system rc file just containsstartup --output_user_root=C:\\_b, so I don't think it makes a difference for this purpose.Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
The command that fails is:
I'm not sure what causes this. I've seen it happen in our CI environment, but not when that command is run directly from a shell. I couldn't reproduce it on a dev machine.
Which operating system are you running Bazel on?
Windows Server 2022, on x86_64
What is the output of
bazel info release?release 8.0.0-pre.20231030.2
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.This is via Bazelisk v1.19.0.
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
Not sure. We first saw this about a week after we upgraded from 7.0.0-pre.20230926.1 to 8.0.0-pre.20231030.2.
Have you found anything relevant by searching the web?
#19250 has the same error message, but that happened on ARM64 whereas I'm seeing this on x86_64. It also seems like that was more consistently reproducible.
Any other information, logs, or outputs that you want to share?
cc @meteorcloudy in case you might know something from #19250 which would affect x86_64 too.
The text was updated successfully, but these errors were encountered: