in reply to Having Win32 Perl crashs using ithreads

Hello dchidelf, and welcome to the monastery.

The following resolves the issue for me. Basically, I'm able to iterate through the loop 20 times. It looks like the *tied* $out and $err handles are not being garbage collected by Perl. Thus, likely memory leaking.

Add a CLOSE method to the IOQueue package.

sub CLOSE {
    undef $_[0];
}

[download]

Inside the test script, close $out and $err handles before calling $p->close().

    print "LOOP DONE\n";
    close $out;
    close $err;
    $p->close();

[download]

The above passes on a Windows 7 VM with Strawberry Perl 5.14.x, 5.16.x, 5.18.x, 5.20.x, and 5.22.x. You may already know this, but $^X is a special variable in Perl. It provides the path for the Perl interpreter.

# my $p = ProcOpen::procopen(\$in, \$out, \$err, "c:\\perl\\bin\\perl.
+exe", "testpipe.pl");

  my $p = ProcOpen::procopen(\$in, \$out, \$err, $^X, "testpipe.pl");

[download]

Your *cool* module is interesting.

Regards, Mario

Replies are listed 'Best First'.
Re^2: Having Win32 Perl crashs using ithreads
by dchidelf (Novice) on Feb 18, 2016 at 21:11 UTC
    Thank you *SO* much Mario!
    I have been heads down digging through perl internals trying to diagnose the crash and didn't see your response.

    Works for me as well!
    I might dig in still to see why it is leading to a crash after just 2 iterations without freeing the IOQueue objects, but it at least gets my project back on track again.

    Thanks again!
    Chad
[reply]

      Hello dchidelf,

      The following is helpful if wanting the ProcOpen module to free up the handles automatically. Basically, this becomes important when omitting the closing of $out and $err handles at the application level.

      Save the $out and $err handles after construction inside the procopen method.

              tie *OFH, "IOQueue", $obuff, $self;
        tie *EFH, "IOQueue", $ebuff, $self;

        $$out = $self->{'outh'} = \*OFH;
        $$err = $self->{'errh'} = \*EFH;

      [download]

      Inside the close method, *untie* the $out and $err handles prior to joining the threads associated with the handles.

              if (! defined $self->{'rc'}) {
                ...

                my $inh     = $self->{'inh'};
                my $outh    = $self->{'outh'};
                my $errh    = $self->{'errh'};
                my $pid     = $self->{'pid'};

        print "About to close\n";

                ...

                $self->{'rc'} = $rc;

                untie *{$outh};
                untie *{$errh};

        print "Join Threads $othr $ethr\n";
                $othr->join();
        print "part done\n";
        print "Join Threads $othr $ethr\n";
                $ethr->join();
        print "Threads joined\n";

                ...

      [download]

      Well, that works just as well. IMHO, leave the *CLOSE* method inside IOQueue in the event one chooses to close the handles at the application level.

      The above changes makes ProcOpen resilient to applications omitting the closing of $out and $err handles.

      Regards, Mario

[reply]
[d/l]
[select]
        Thanks I added calls to my IOQueue close functions in the ProcOpen::close and also untied the variables as you suggested.

        Since I got around the crashes I have also replaced the temp files used for the process STDOUT/STDERR with pipes, so that simplifies some of the processing (don't need to tail the files, can just read from the pipe until it closes). All seems well with it.

        Here is the "final" module if anyone is interested.
        Read more... (20 kB)
[reply]
[d/l]

In Section Seekers of Perl Wisdom