Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Cross-platform support: macOS and Windows architecture and test coverage

Aperta
  • Qualcosa non va?
#4,893 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 8 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
5/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
cmake, macos, postgresql, python, sqlalchemy, sqlite
Ambito
backend, cli, devops, testing-qa

Direzione di ricerca

This is a tracking issue, not a single task: the spawn-worker design lives in PR #4883 (macOS) and PR #4885 (Windows), with the server start-up path around _build_worker_server() and the multiprocess start-method selection. Read those PRs and the failing CI jobs before touching anything. Done would mean one of the unchecked items, such as the Windows socket.share() work, lands with its tests passing on the matching platform.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

good to go :rocket:

Summary

CodeChecker has growing demand for macOS and Windows support. This issue documents the architectural situation, what has been implemented, what remains, and links all related issues and PRs.

The core problem: fork() is not portable

CodeChecker's server uses a pre-fork worker model. This is fundamentally incompatible with macOS and Windows:

  • macOS: fork() crashes when the Objective-C runtime has initialized framework classes (Security.framework). This is triggered by import sqlalchemy → asyncio → ssl → libcrypto → Security.framework. Since SQLAlchemy is needed before workers spawn (DB migrations, product registration), this import chain cannot be deferred. See vLLM encountering the same issue.
  • Windows: has no fork() at all.
  • Python 3.14: changed the default start method on Linux from fork to forkserver (#4773), breaking the server there too.

Solution: spawn-based workers on non-Linux

Implemented in PR #4883 (macOS) and partially in PR #4885 (Windows):

  • multiprocess.set_start_method("spawn") on non-Linux platforms
  • DupFd for socket passing to spawn workers
  • _build_worker_server() reconstructs the full HTTPServer in each worker
  • SyncManager proxies for Queue/Value/dict (picklable across spawn boundary)
  • Pool logging initializers (spawn workers don't inherit parent logging config)
  • Linux retains fork for performance (no import overhead)

Current status

Component Linux macOS Windows
Analyzer ✅ ✅ 🚧 PR #4885
Store client ✅ ✅ 🚧
Server (API workers) ✅ ✅ (spawn) needs socket.share()
Server (task workers) ✅ ✅ (spawn) needs socket.share()
OAuth ✅ ✅ ✅
Build logging (codechecker log) ✅ (ld-logger) ❌ needs Bear/cmake/scan-build? ❌ needs Bear/cmake
CI tests ✅ ✅ (sqlite) 🚧 PR #4885

Performance on macOS CI

Spawn workers must import all 887 Python files from scratch. On GitHub Actions macOS runners (slow VM I/O):

  • Import time: 36s per worker (vs 0.26s locally — 133x slower I/O)
  • Server ready with 1+1 workers: ~42s
  • Server ready with 2+2 workers: ~84s

This is an infrastructure constraint (VM storage latency), not a code issue.

Related issues

  • #4773 — Server cannot start under Python 3.14 (forkserver default) — same root cause
  • #4733 — max_workers parameter incompatibility on macOS/Windows
  • #4338 — Pool() unexpected argument on server init
  • #555 — Original Windows porting tracking issue
  • #4678 — Need Bear for macOS build logging (ld-logger is Linux-only)
  • #1984 — Fix tu_collector on macOS
  • #2574 — Enable tu_collector tests on macOS
  • #4296 — Cannot use store on Windows
  • #4277 — Windows escaped paths in compile_commands.json
  • #4802 — diagtool not found on Windows
  • #3542 — Cannot pickle _thread._local object (spawn-related)
  • #3654 — Windows file paths not handled by server
  • #4032 — Python 3.12 incompatibility on Windows

Related PRs

  • #4883 — macOS test support (spawn implementation, CI, test fixes)
  • #4885 — Windows test support (exploratory)
  • #4734 — multiprocessing compatibility wrapper for macOS/Windows
  • #4452 — Pool shim class for compat
  • #4096 — Earlier attempt at macOS CI (workflow-only, no code fixes)
  • #4095 — Earlier attempt to use multiprocess library on all platforms (closed)
  • #4673 — ld_logger not available on macOS (merged)

Remaining work

macOS (short term)
  • Stabilize CI: all functional tests passing (PR #4883 in progress)
  • Build logging: integrate Bear as alternative to ld-logger (#4678)
  • PostgreSQL testing on macOS CI (lower priority — SQLite proves the code path)
Windows (medium term)
  • socket.share()/socket.fromshare() for Windows socket passing in server
  • Path handling fixes (#4277, #3654)
  • Build logging solution (cmake compile_commands or Bear)
  • Windows CI stabilization (PR #4885)
Python 3.14 (high priority)
  • The spawn implementation from #4883 also fixes #4773 since it handles non-fork start methods. Needs testing on Linux with Python 3.14.
Lingua principale
Python
Stelle
2.6k
Fork
494
Merge medio
6g 22h
PR unite (30g)
21

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ericsson/codechecker

Tutte le issue di Ericsson/codechecker

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.