github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-05 23:53:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[PR #15371] mlx: delay initialization to prevent access violation on systems without compatible GPU #20397

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

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/15371
Author: @CynaCons
Created: 4/6/2026
Status: 🔄 Open

Base: main ← Head: fix/mlx-init-gpu-check-14952

📝 Commits (1)

  • bb23d5a mlx: delay initialization to prevent access violation on systems without compatible GPU

📊 Changes

2 files changed (+69 additions, -59 deletions)

View changed files

📝 x/imagegen/cmd/engine/main.go (+2 -3)
📝 x/imagegen/mlx/mlx.go (+67 -56)

📄 Description

Problem

On Windows (and potentially Linux) systems without NVIDIA GPUs, ollama crashes immediately on startup with Exception 0xc0000005 (access violation) in _Cfunc_mlx_random_key. This affects users with Intel and AMD GPUs.

The crash happens because the MLX package's init() function runs unconditionally on import. It calls mlx_random_key which attempts GPU operations via the CUDA backend. On systems without CUDA-capable hardware, this causes an OS-level access violation that bypasses the safe error handler added in #14777 — that handler catches MLX-reported errors, but not Windows structured exceptions.

The root cause was introduced in #14642 which removed the //go:build mlx constraint, making the MLX package compile and initialize on all platforms by default.

Fix

  • Remove init() entirely — no MLX code runs at package import time
  • Consolidate all initialization into InitMLX() behind sync.Once for thread safety
  • Add GPU backend availability check (mlx_cuda_is_available / mlx_metal_is_available) before calling RandomKey, as defense in depth
  • Update the image generation engine (x/imagegen/cmd/engine/main.go) to call InitMLX() explicitly

This means the vast majority of users (who use ollama for text LLMs, not MLX image generation) never execute any MLX code at all.

Testing

  • Manually tested on Windows 11 Home (AMD64, no NVIDIA GPU): ollama v0.20.2 crashes on startup; with this patch applied, ollama starts and runs normally with MLX gracefully unavailable.
  • MLX image generation path is unchanged — InitMLX() performs the same initialization steps, just on-demand instead of at import.

Fixes #14952

🔄 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/15371 **Author:** [@CynaCons](https://github.com/CynaCons) **Created:** 4/6/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/mlx-init-gpu-check-14952` --- ### 📝 Commits (1) - [`bb23d5a`](https://github.com/ollama/ollama/commit/bb23d5a257218a90e3d0290c42319dc59d71e210) mlx: delay initialization to prevent access violation on systems without compatible GPU ### 📊 Changes **2 files changed** (+69 additions, -59 deletions) <details> <summary>View changed files</summary> 📝 `x/imagegen/cmd/engine/main.go` (+2 -3) 📝 `x/imagegen/mlx/mlx.go` (+67 -56) </details> ### 📄 Description ## Problem On Windows (and potentially Linux) systems without NVIDIA GPUs, ollama crashes immediately on startup with `Exception 0xc0000005` (access violation) in `_Cfunc_mlx_random_key`. This affects users with Intel and AMD GPUs. The crash happens because the MLX package's `init()` function runs unconditionally on import. It calls `mlx_random_key` which attempts GPU operations via the CUDA backend. On systems without CUDA-capable hardware, this causes an OS-level access violation that bypasses the safe error handler added in #14777 — that handler catches MLX-reported errors, but not Windows structured exceptions. The root cause was introduced in #14642 which removed the `//go:build mlx` constraint, making the MLX package compile and initialize on all platforms by default. ## Fix - **Remove `init()` entirely** — no MLX code runs at package import time - **Consolidate all initialization into `InitMLX()`** behind `sync.Once` for thread safety - **Add GPU backend availability check** (`mlx_cuda_is_available` / `mlx_metal_is_available`) before calling `RandomKey`, as defense in depth - **Update the image generation engine** (`x/imagegen/cmd/engine/main.go`) to call `InitMLX()` explicitly This means the vast majority of users (who use ollama for text LLMs, not MLX image generation) never execute any MLX code at all. ## Testing - **Manually tested on Windows 11 Home (AMD64, no NVIDIA GPU):** ollama v0.20.2 crashes on startup; with this patch applied, ollama starts and runs normally with MLX gracefully unavailable. - MLX image generation path is unchanged — `InitMLX()` performs the same initialization steps, just on-demand instead of at import. Fixes #14952 --- <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:35:17 -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#20397
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?