RGFs built after a module is re-evaluated at the same path get the old module's id and run its code

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

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
julia
Área
backend

Línea de trabajo

Start with expr_to_id and _hash_module! in the change from #157, then trace how _cache_body and generated_callfunc use the resulting id. Reproduce the collision with the included Julia snippet on Julia 1.10.12 and compare the first and second module evaluations. Done means RGFs for a re-evaluated module run its new definitions while preserving the session-stable ids described for package images.

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

Descripción

I'm not entirely sure why my AI ran into this issue, but seems legitimate, even if the use case is probably very silly?

Bug report with reproducer: since 0.5.27 hashes modules by path, an RGF over a re-evaluated module shares the replaced module's id and body; sketch of a per-path generation fix. · ReactiveKernels:snag.prepared-kernel-b879ce51 · claude-fable-5-1@xhigh

expr_to_id hashes a Module or a GlobalRef's module by fullname (_hash_module!, since #157 in 0.5.27). That is what keeps ids stable across sessions and lets an RGF baked into a package image match the one built at run time. But a module evaluated a second time at the same path is a new module object with the same name: include a file with a module block twice, include_string it again, or re-evaluate a submodule while developing a package. An RGF built over the new module's bindings then gets the id of one built over the old module. Both have the same type, _cache_body keeps the first body as the canonical one for that id, and generated_callfunc runs it, so the new function calls the old module's definitions.

using RuntimeGeneratedFunctions
RuntimeGeneratedFunctions.init(@__MODULE__)
src(factor) = "module M\ng(x) = $(factor) * x\nend"
function build()
    M = Base.invokelatest(getglobal, Main, :M)
    RuntimeGeneratedFunction(@__MODULE__, @__MODULE__, :(x -> $(GlobalRef(M, :g))(x)))
end
include_string(Main, src(2)); f1 = build(); r1 = Base.invokelatest(f1, 1.0)
include_string(Main, src(3)); f2 = build(); r2 = Base.invokelatest(f2, 1.0)
@show r1 r2 typeof(f1) === typeof(f2)

On Julia 1.10.12 with RuntimeGeneratedFunctions 0.5.27, both the registry release and master at ef815dc6a50288bb6a70510f867a92c797649c99, this prints

r1 = 2.0
r2 = 2.0
typeof(f1) === typeof(f2) = true

f2 references the second M, whose g is 3x, but it returns 2.0. In a fresh session the same build() over the second definition gives r2 = 3.0, and f1 and f2 have distinct types. Nothing fails loudly, so after editing a function and re-including the module, generated code keeps running the previous version.

One way to fix it without giving up the session-stable ids from #157: keep, per module path, the order in which distinct module objects at that path were first hashed in this session, and fold the position into the hash only when it is not 0. Ids of RGFs that reference only the first module seen at each path then stay exactly what they are now, so package images keep matching, while a replacement gets its own id. One corner case: when a package image is loaded and one of its modules is replaced before any RGF references it, the replacement would be the first module hashed at that path. Recording each loaded package's module tree first, for example from a Base.package_callbacks entry, closes that.

A downstream package that compiles generated programs through RGF hit this when a function defined in a re-included module kept calling the replaced module's definitions. It now prepends a marker carrying such generation numbers to its own bodies before constructing the RGF, which sidesteps the collision for its own programs but not for other users.

Lenguaje dominante
Julia
Estrellas
114
Forks
19
Merge medio
2 h 42 min
PR fusionados (30 d)
1

Preparar el entorno

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 SciML/RuntimeGeneratedFunctions.jl

Todos los issues de SciML/RuntimeGeneratedFunctions.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.