Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Dist::Zilla Config::MVP objects spuriously resurrect during global destruction

Open
#1,515 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
28/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
perl
Domain
compilers

Research direction

Start by running prove -v t/commands/listdeps.t under standard Perl and PerlOnJava, comparing the captured output and the global-destruction diagnostics. Investigate the PerlOnJava ownership and destruction path for the Dist::Zilla object graph, especially Config::MVP::Sequence and Dist::Zilla::MVP::Assembler::Zilla. Done means the focused test and affected command-output assertions no longer receive diagnostics that standard Perl does not produce.

Written by the indexing model from the issue text.

Description

area:cpan-port area:memory area:runtime bug

Summary

PerlOnJava spuriously reaches global-destruction resurrection for Dist::Zilla's Moose/Config::MVP object graph. It emits diagnostics such as:

DESTROY created new reference to dead object 'Config::MVP::Sequence' during global destruction.
DESTROY created new reference to dead object 'Dist::Zilla::MVP::Assembler::Zilla' during global destruction.

Those diagnostics are Perl-compatible when a destructor really revives an object, but the unmodified Dist::Zilla suite does not produce them under standard Perl. Under PerlOnJava they contaminate subprocess output and break command-output assertions.

Oracle and impact

CPAN random run 20260924-115230-59978 tested pure-Perl Dist::Zilla 6.039. Its complete unmodified suite passes with isolated standard Perl 5.42.2: 57 files, 504 tests, Result: PASS.

The PerlOnJava JVM acceptance run fails 38 of 531 subtests across 5 files. In t/commands/listdeps.t, the extra global-destruction diagnostics appear in the captured dependency-list output. A focused interpreter run emits the same diagnostics while executing the first listdeps subtest; the test is bounded but slow under the interpreter.

Focused reproducer

With Dist::Zilla's ordinary test prerequisites:

prove -v t/commands/listdeps.t

Expected on standard Perl: dependency-list output only. Actual on PerlOnJava: the output additionally contains the Config::MVP::Sequence and Dist::Zilla::MVP::Assembler::Zilla global-destruction resurrection diagnostics.

This is intentionally distinct from issue #1473: that issue covers false CORE::try / CORE::catch ambiguity warnings. This issue covers the runtime reaching an unexpected resurrection state for the Dist::Zilla object graph.

Expected behavior

PerlOnJava must preserve the relevant ownership and destruction ordering so these objects do not reach a resurrection warning during the normal Dist::Zilla command lifecycle. The diagnostics must not be injected into command output when standard Perl produces none.

Duplicate search

No existing issue matched Config::MVP::Sequence or Dist::Zilla::MVP::Assembler::Zilla. The only broad global-destruction search result, issue #1144, concerns pseudofork runtime cloning rather than object-lifecycle resurrection.

Dominant language
Perl
Stars
64
Forks
6
Avg merge
4h 42m
Merged PRs (30d)
170

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fglock/PerlOnJava

All issues in fglock/PerlOnJava

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.