github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-22 05:31:43 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[PR #14712] progress: fix data race on shared fields in stop/start #20075

New Issue
Open
opened 2026-04-16 07:25:41 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-16 07:25:41 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/14712
Author: @gambletan
Created: 3/8/2026
Status: 🔄 Open

Base: main ← Head: fix/progress-race-condition

📝 Commits (1)

  • 3a0acc2 progress: fix data race on states, ticker, and pos fields

📊 Changes

1 file changed (+15 additions, -4 deletions)

View changed files

📝 progress/progress.go (+15 -4)

📄 Description

What

Fix data races in progress.Progress between the background render goroutine and Stop()/StopAndClear() calls.

Why

The stop() method accesses p.states (iterating to stop spinners) and p.ticker (reading + writing) without holding p.mu. Meanwhile:

  • Add() appends to p.states under the mutex
  • render() reads/writes p.pos and reads p.states under the mutex
  • start() writes p.ticker without the mutex

This is a data race detectable by go test -race. Since Stop() and StopAndClear() are called from the main goroutine while start()/render() run in a background goroutine, concurrent access is expected.

Additionally, StopAndClear() reads p.pos (line 75) without the mutex while render() writes it.

Change

  • Hold p.mu in stop() when accessing p.states, p.ticker
  • Hold p.mu in start() when writing p.ticker
  • Hold p.mu in StopAndClear() when reading p.pos
  • Extract renderLocked() so stop() can render while already holding the mutex

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/14712 **Author:** [@gambletan](https://github.com/gambletan) **Created:** 3/8/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/progress-race-condition` --- ### 📝 Commits (1) - [`3a0acc2`](https://github.com/ollama/ollama/commit/3a0acc24d8874315c4c02fec9646d6a6e1de0d60) progress: fix data race on states, ticker, and pos fields ### 📊 Changes **1 file changed** (+15 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `progress/progress.go` (+15 -4) </details> ### 📄 Description ## What Fix data races in `progress.Progress` between the background render goroutine and `Stop()`/`StopAndClear()` calls. ## Why The `stop()` method accesses `p.states` (iterating to stop spinners) and `p.ticker` (reading + writing) without holding `p.mu`. Meanwhile: - `Add()` appends to `p.states` under the mutex - `render()` reads/writes `p.pos` and reads `p.states` under the mutex - `start()` writes `p.ticker` without the mutex This is a data race detectable by `go test -race`. Since `Stop()` and `StopAndClear()` are called from the main goroutine while `start()`/`render()` run in a background goroutine, concurrent access is expected. Additionally, `StopAndClear()` reads `p.pos` (line 75) without the mutex while `render()` writes it. ## Change - Hold `p.mu` in `stop()` when accessing `p.states`, `p.ticker` - Hold `p.mu` in `start()` when writing `p.ticker` - Hold `p.mu` in `StopAndClear()` when reading `p.pos` - Extract `renderLocked()` so `stop()` can render while already holding the mutex --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-16 07:25:41 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#20075
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?