Reading a deleted namespace scalar recreates its stash entry
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 57/100
Línea de trabajo
Start with RuntimeStash.deleteNamespace and the stash enumeration path in HashSpecialVariable, then inspect t/basic.t and the standalone reproduction described in the issue. Trace how a qualified undefined scalar is handled after its namespace is deleted. Done means the child namespace remains absent after the scalar read, matching Perl's behavior on both PerlOnJava backends.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
Deleting a package namespace from its parent stash does not keep that namespace deleted after a qualified scalar is read. This makes Text::Template 1.61's _scrubpkg cleanup assertion fail in t/basic.t on both PerlOnJava backends. System Perl passes the assertion, and the complete upstream suite passes there (22 files, 184 tests). The failure is included in archived CPAN run 20261104-151051-20617.
Root cause
RuntimeStash.deleteNamespace removes the namespace's current slots and marks the package freed. But stash enumeration in HashSpecialVariable reconstructs child-package entries from any qualified global slot it finds. A later read such as $Cleanup::GEN0::test creates an undefined scalar slot; enumeration then infers GEN0:: as a live child stash from that slot and exposes it again. The enumeration path does not honor the freed-stash marker, so this implicit scalar autovivification makes exists $Cleanup::{"GEN0::"} true again. The standalone script in the comment reproduces the behavior without a CPAN dependency.
Expected behavior
Reading an undefined scalar below a namespace deleted from its parent stash must not recreate that child namespace entry. Perl leaves the child absent in the same sequence.
- Lenguaje dominante
- Perl
- Estrellas
- 65
- Forks
- 8
- Merge medio
- 5 h 45 min
- PR fusionados (30 d)
- 184
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de fglock/PerlOnJava
-
area:runtime documentation enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
fglock/PerlOnJava#1579 ·
Los mantenedores suelen responder en 1 día
-
area:backend bug
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
fglock/PerlOnJava#1981 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area:parser bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
fglock/PerlOnJava#1979 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area:cpan-port bug
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
fglock/PerlOnJava#1962 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
fglock/PerlOnJava#1961 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de fglock/PerlOnJava
Issues similares
-
ai-driven-fuzzing bug claude Minor
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
linagora/lemonldap-ng-plugins#170 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
libwww-perl/HTTP-Message#236 ·
-
1.severity: security
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
RTCP SR/RR length check ignores the fixed header, report blocks are read past the packet endAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 2 días
-
wave-followup
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100