Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de 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

Abierto
  • ¿Algo no está bien?
#1,162 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c
Área
compilers, documentation, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C
Estrellas
3
Forks
7
Merge medio
4 h 7 min
PR fusionados (30 d)
112

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de InauguralSystems/EigenScript

Todos los issues de InauguralSystems/EigenScript

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.