0.74.1: memory grows to ~106 GiB; system becomes unresponsive and requires forced restart

Aperta
  • Qualcosa non va?
#4,512 5 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
sqlite, swift
Ambito
desktop-dev, performance

Direzione di ricerca

The payload names no source files, only the process (CodexBar, PID 84042) and disk-write stacks through sqlite3_exec, sqlite3_wal_checkpoint_v2 and sqlite3WalCheckpoint. Start by reproducing steady footprint growth in a long-running session and capturing an allocation or retained-object profile. The issue does not define done; a fix would need a confirmed retaining owner and a bounded footprint under sustained use.

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

Descrizione

clawsweeper:fix-shape-clear clawsweeper:needs-maintainer-review clawsweeper:no-new-fix-pr impact:crash-loop issue-rating: 🦪 silver shellfish P1

Summary

CodexBar 0.74.1 (167) grew from roughly 1.8 GB to 37 GB overnight, then reached about 105.9 GiB of accounted memory in a macOS Jetsam report. Later that morning, multiple apps became unresponsive and I had to force restart my 96 GiB Mac.

The memory growth is directly recorded in macOS diagnostics. It is the strongest suspect for the systemwide hang, but I do not have an allocation trace proving the retaining owner or a process snapshot from the exact moment the apps stopped responding.

Related: #3323 and #4486. This adds diagnostic evidence from 0.74.1 with substantially larger growth and a systemwide failure.

Environment

  • CodexBar: 0.74.1 (build 167)
  • macOS: 15.6.1 (24G90)
  • Hardware: Apple Silicon MacBook Pro, model Mac14,6, 96 GiB RAM, 12 CPU cores
  • Incident: October 13–14, 2026; all times below are UTC+07:00
  • Provider configuration, refresh interval, and cost-tracking state at the time of the incident were not captured in this investigation.

Recorded memory growth

The reports identify the same CodexBar process, PID 84042:

Time Recorded memory
Oct 13, 22:55–23:15 Footprint grew from 1,805.86 MB to 7,999.28 MB
Oct 13, 23:15–Oct 14, 00:19 Footprint grew from 7,999.28 MB to 37.02 GB
Oct 14, 02:44:12 Jetsam named CodexBar largestProcess: 6,938,218 pages × 16,384 bytes ≈ 105.87 GiB

The Jetsam accounting includes compressed memory; this is not 106 GiB of resident physical RAM. At 02:44, the system compressor occupied approximately 48.25 GiB, representing 215.40 GiB uncompressed, and free pages totaled about 199 MiB.

Selected excerpts:

CodexBar_2026-10-14-001947...diag:
Version:          0.74.1 (167)
PID:              84042
Footprint:        7999.28 MB -> 37.02 GB (+29.21 GB)
Start time:       2026-10-13 23:15:46.687 +0700
End time:         2026-10-14 00:19:46.801 +0700
Writes:           8589.94 MB of file backed memory dirtied over 3840 seconds

{
  "date": "2026-10-14 02:44:12.03 +0700",
  "largestProcess": "CodexBar",
  "pageSize": 16384,
  "compressorSize": 3162431,
  "uncompressed": 14116692,
  "freePages": 12745,
  "process": {
    "name": "CodexBar",
    "pid": 84042,
    "rpages": 6938218,
    "physicalPages": { "internal": [224507, 6677480] }
  }
}

The JSON above is an extract of selected fields, with memory-status fields flattened for readability. The disk-write report's hot stacks included sqlite3_exec, sqlite3_wal_checkpoint_v2, sqlite3WalCheckpoint, and guarded_pwrite_np; this identifies substantial database activity, but does not prove it caused the memory growth.

User-visible impact

  • By 08:04:14, repeated attempts to open or activate several unrelated apps were failing to respond.
  • Unified logs repeatedly reported Received memory pressure event: 16, system vm pressure critical: 1 approximately every 30 seconds throughout the checked 07:30–08:07:58 window.
  • A normal restart was requested at 08:07:42. I then attempted a terminal restart and ultimately had to force restart; the Mac booted at 08:09:15. The reset diagnostic records btn_rst,finger_reset force_off.

The shutdown-stall sample was taken at 08:08:14, after GUI teardown, and CodexBar was already absent. It cannot establish CodexBar's footprint at 08:04 or the precise onset of the hang. Other development processes were also running, so I am not claiming CodexBar was the only source of memory pressure.

Expected behavior / reproduction status

CodexBar's memory should remain bounded during long-running use. This is one observed incident backed by multiple OS diagnostic snapshots; I do not yet have deterministic reproduction steps or an Instruments retained-object profile. The process's continuous growth across several hours warrants investigation even without assigning a specific cache or parser as the cause.

Lingua principale
Swift
Stelle
22.9k
Fork
2.2k
Merge medio
1g 1h
PR unite (30g)
399

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 steipete/CodexBar

Tutte le issue di steipete/CodexBar

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.