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

Embed API: a host thread that attaches to a state, evaluates, and detaches frees its intern table — names it interned (dict keys AND global env bindings, builtins included) dangle for every other thread of that state

Aperta
  • Qualcosa non va?
#1,162 0 commenti 0 reazioni 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
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
compilers, documentation, testing-qa

Direzione di ricerca

Start with docs/EMBEDDING.md and the cited intern-table paths in src/eigenscript.c, then trace attach, detach, and evaluation through src/eigs_embed.c. Reproduce the lifetime failure with the reported scratchpad harness and add the attach/eval/detach/attach-again case to src/embed_concurrent.c. Done means state-owned names remain usable across host-thread detach and reattach without sanitizer errors.

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

Descrizione

area:concurrency area:embed bug

Found by a blind critic during the #1141 review. Pre-existing on main b87bb25; NOT fixed by #1141, whose re-homing is gated on the per-state spawn flag (state->multithreaded), which this shape never sets.

The shape (documented in docs/EMBEDDING.md)

"Inside a state, multiple OS threads can attach (one EigsThread each) and share the state's global env … eigs_thread_detach is called from the same thread before … the thread exits." No spawn is involved, so multithreaded stays 0 and every thread interns names into ITS OWN table (eigs_current->intern_tbl), which eigs_thread_detach → eigs_thread_drain_caches → env_intern_table_unref frees.

Repro (C harness against the ASan objects; scratchpad/host_multiattach.c in the critic's report)

T1: attach, init runtime, eval d is {"pre": 1} and d.from_t1 is 42, detach. T2: attach, eval str of (1 + 2), then keys of d.

==2072370==ERROR: AddressSanitizer: heap-use-after-free ... READ of size 1 thread T2
  #0 strcmp  #1 env_hash_find src/eigenscript.c:2729  #2 env_get_hashed :4331  #3 env_get
  #4 compile_ast src/compiler.c:4000  #5 eval_source src/eigs_embed.c:167  #6 eigs_eval_string
freed by thread T1: #1 env_intern_table_unref src/eigenscript.c:1545

Release build: T2 gets Error line 1: undefined variable 'str' and every read of d returns null. Same result when the SAME OS thread detaches and re-attaches. Identical on b87bb25 and on the #1141 branch.

Why it is wider than dict keys

The global env's names[] — every builtin registered by T1 during init — lives in T1's table. After T1 detaches, the state is unusable from any thread. #1141 closed the dict-key half for the spawn shape only; this is the same lifetime bug one level up, for the host-thread shape.

Fix direction

The intern-table lifetime must be the STATE's, not the thread's, for any name that lands in state-owned structures (global env bindings, module envs, dict keys). Options: the state holds a reference on every attached thread's table (the #1065 chunk-refcount shape, generalised), or the global env re-homes its names into the state-owned table at detach, or interning for state-owned structures always goes to a state-level table and per-thread tables serve only thread-local scratch. Whichever: docs/EMBEDDING.md's multi-attach paragraph becomes true, and src/embed_concurrent.c gains the attach/eval/detach/attach-again case (it does not have one — that is why this was never seen).

Relation to #1141's docs

The #1141 branch scopes its CONCURRENCY.md guarantee to "once the program has spawned" and points here for the host-thread shape.

Lingua principale
C
Stelle
3
Fork
7
Merge medio
4h 7m
PR unite (30g)
112

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 InauguralSystems/EigenScript

Tutte le issue di InauguralSystems/EigenScript

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.