Skip to content

Preserve state variables across file-reading loops #1475

Description

@fglock

Summary

DataExtract::FixedWidth 0.09 fails two upstream tests under PerlOnJava because a state variable declared inside a file-reading loop does not retain the constructed object between iterations. The first iteration should initialize $fw; on the next iteration $fw is undefined and the test dies calling parse.

Reproduction

This was found in CPAN random run 20260921-124328-13959 at PerlOnJava commit d8e4fd417.

The affected upstream tests are:

  • t/03-Nulls.t
  • t/04-Fix-Overlay.t

Both tests have the same relevant structure:

while (my $line = <$fh>) {
    state $fw;

    if ($. == 1) {
        $fw = DataExtract::FixedWidth->new({
            header_row   => $line,
            null_as_undef => 1, # or fix_overlay => 1
        });
    }
    else {
        my $arr_ref = $fw->parse($line);
    }
}

Under PerlOnJava, the constructor branch runs for the first line, but $fw is undefined on the second line. The test then dies with:

Can't call method "parse" on an undefined value

The failure reproduces when running the actual test files with both the JVM backend and the interpreter backend. It is not a timeout or a dependency-installation failure.

Expected behavior

state $fw should retain its value for subsequent loop iterations, as it does under standard Perl. The first line should construct a DataExtract::FixedWidth object and later lines should call parse on that same object.

Results

Standard Perl passes the focused tests:

t/03-Nulls.t ........ ok
t/04-Fix-Overlay.t .. ok
All tests successful.
Files=2, Tests=15

The archived standard-Perl oracle also passes the complete distribution suite: 18 test files, 82 tests.

PerlOnJava fails:

t/03-Nulls.t       exited 255; planned 12 tests, ran 0
t/04-Fix-Overlay.t exited 255; planned 3 tests, ran 0
Files=18, Tests=68
Failed 2/18 test programs

The remaining 16 test programs pass. The test files are reproducible on both PerlOnJava execution backends.

Suspected area

The immediate failure surface is lowering or runtime handling of file-scoped state variables in this loop context. The interaction with Perl's $. input-line counter is also worth checking: the initialization branch is selected using $. == 1, and PerlOnJava may be handling the line counter or its association with the newly opened filehandle differently in the failing source-file context.

A simple scalar state loop can appear to work in a minimal -e invocation, so the regression test should preserve the source-file form, filehandle read loop, $. == 1 branch, and object assignment shown above.

Environment and scope

  • Distribution: DataExtract::FixedWidth 0.09
  • PerlOnJava backends: JVM and interpreter
  • Standard Perl oracle: Perl 5.42.2 on macOS
  • Native/XS code: none
  • Reverse-dependency analysis: not applicable; this is a pure-Perl distribution

This is an upstream compatibility failure, not a failure caused by missing services, display requirements, native libraries, or unsupported XS code.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:backendJVM interpreter or execution-backend behaviorarea:cpan-portCPAN compatibility ports and providersarea:runtimeCore Perl runtime semanticsbugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions