bazelbuild / bazelbuild/bazel

Very slow build seemingly "stuck" in noFollowStatErrno

Open
#22,879 0 comments 0 reactions 0 assignees View on GitHub
team-Core type: bug untriaged
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 16h
Merged PRs (30d)
72

Description

### 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 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_

Contributor guide

Open the contributing guide

Research direction

Start by inspecting InMemoryFileSystem.noFollowStatErrno and the history that introduced its synchronized modifier. Use the reported jstack contention and symlink-resolution path to determine whether the lock is required under concurrent access. Done means the synchronization requirement is established or safely changed, with the reported contention addressed.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
build-system, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.