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 was just running a build with the IntelliJ aspect to try to debug a problem with the aspect and Bazel got stuck in "checking cached actions" for a really long time. This build was executed after another equal build that had almost completed, but I had to shut the server down. Upon restart of the second build is when I noticed this long-running process.
Looking at jstack, I saw various threads stuck deep down resolving symlinks, and various were waiting on the monitor lock for InMemoryFileSystem.noFollowStatErrno. Digging through the code, I don't understand why this method needs to be synchronized, and looking at the history of the code, this seems to come from an older implementation that needed it.
I can't quite assess whether synchronized can be removed or not, so I'm filing this so that the experts can take a look 📦
Which category does this issue belong to?
Core
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
N/A. Code question.
Which operating system are you running Bazel on?
Linux but this is irrelevant.
What is the output of bazel info release?
7.0.2
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
N/A
What's the output of git remote get-url origin; git rev-parse HEAD ?
N/A
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered:
Description of the bug:
I was just running a build with the IntelliJ aspect to try to debug a problem with the aspect and Bazel got stuck in "checking cached actions" for a really long time. This build was executed after another equal build that had almost completed, but I had to shut the server down. Upon restart of the second build is when I noticed this long-running process.
Looking at jstack, I saw various threads stuck deep down resolving symlinks, and various were waiting on the monitor lock for
InMemoryFileSystem.noFollowStatErrno
. Digging through the code, I don't understand why this method needs to besynchronized
, and looking at the history of the code, this seems to come from an older implementation that needed it.I can't quite assess whether
synchronized
can be removed or not, so I'm filing this so that the experts can take a look 📦Which category does this issue belong to?
Core
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
N/A. Code question.
Which operating system are you running Bazel on?
Linux but this is irrelevant.
What is the output of
bazel info release
?7.0.2
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.N/A
What's the output of
git remote get-url origin; git rev-parse HEAD
?N/A
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: