Skip Menu |
 

This queue is for tickets about the IPC-Open3-Utils CPAN distribution.

Report information
The Basics
Id: 67389
Status: resolved
Priority: 0/
Queue: IPC-Open3-Utils

People
Owner: Nobody in particular
Requestors: scott [...] perlcode.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.8
Fixed in: (no value)



Subject: read loop hanging even when all handles are closed
Download (untitled) / with headers
text/plain 1.5k
I'm running Perl 5.10.1 on FreeBSD 8.2 with IPC::Open3::Utils 0.8. I cannot duplicate this on Centos 5.4/Perl 5.8.8 (another system I use with an equivalent setup) or older FreeBSD versions running 5.8.8. I use run_cmd() like this: IPC::Open3::Utils::run_cmd (@ssh, $target, '/bin/sh', { autoflush => { stdout => 1, stderr => 1, stdin => 1 }, pre_read_print_to_stdin => $some_script, close_stdin => 1, }); run_cmd() never returns. I found by tracing the process it's stuck in the READ_LOOP block of run_cmd() in the call to $sel- Show quoted text
>can_read. More tracing reveals it's hung in a call to Perl's select() while trying to see if there are any readable filehandles. While
both handles (stdout, stderr) have already been closed in run_cmd(), IO::Select is still trying to read them (there may be a deeper bug here in IO::Select). A workaround I found is to remove the defunct handles from the IO::Select object before closing them in run_cmd(): --- Utils.pm.orig 2010-05-21 15:50:29.000000000 +0100 +++ Utils.pm 2011-04-11 20:15:31.000000000 +0100 @@ -212,6 +212,7 @@ HANDLE: for my $fh (@ready) { if ( $fh->eof ) { + $sel->remove($fh); $fh->close; next HANDLE; } This technique is consistent with and recommended by IO::Select's documentation on how to deal with completed handles (see IO::Select's EXAMPLE section).
Subject: Re: [rt.cpan.org #67389] read loop hanging even when all handles are closed
Date: Mon, 11 Apr 2011 15:43:20 -0500
To: bug-IPC-Open3-Utils [...] rt.cpan.org
From: Dan Muey <webmaster [...] simplemood.com>
thanks, excellent find! I'll try and address that ASAP On Apr 11, 2011, at 2:34 PM, scott@perlcode.org via RT wrote: Show quoted text
> Mon Apr 11 15:34:40 2011: Request 67389 was acted upon. > Transaction: Ticket created by scott@perlcode.org > Queue: IPC-Open3-Utils > Subject: read loop hanging even when all handles are closed > Broken in: 0.8 > Severity: Important > Owner: Nobody > Requestors: scott@perlcode.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=67389 > > > > I'm running Perl 5.10.1 on FreeBSD 8.2 with IPC::Open3::Utils 0.8. I cannot duplicate this on Centos 5.4/Perl 5.8.8 (another > system I use with an equivalent setup) or older FreeBSD versions running 5.8.8. > > I use run_cmd() like this: > > IPC::Open3::Utils::run_cmd > (@ssh, $target, '/bin/sh', > { autoflush => { stdout => 1, > stderr => 1, > stdin => 1 }, > pre_read_print_to_stdin => $some_script, > close_stdin => 1, > }); > > run_cmd() never returns. I found by tracing the process it's stuck in the READ_LOOP block of run_cmd() in the call to $sel-
>> can_read. More tracing reveals it's hung in a call to Perl's select() while trying to see if there are any readable filehandles. While
> both handles (stdout, stderr) have already been closed in run_cmd(), IO::Select is still trying to read them (there may be a > deeper bug here in IO::Select). > > A workaround I found is to remove the defunct handles from the IO::Select object before closing them in run_cmd(): > > --- Utils.pm.orig 2010-05-21 15:50:29.000000000 +0100 > +++ Utils.pm 2011-04-11 20:15:31.000000000 +0100 > @@ -212,6 +212,7 @@ > HANDLE: > for my $fh (@ready) { > if ( $fh->eof ) { > + $sel->remove($fh); > $fh->close; > next HANDLE; > } > > This technique is consistent with and recommended by IO::Select's documentation on how to deal with completed handles (see > IO::Select's EXAMPLE section).
Thanks again, sorry for the delay. This should be addressed in v0.91 just uploaded to CPAN.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.