RE: Cygwin1.dll 1.7.1 causes ActivePerl 5.10 hang on gzip pipe close on Windows Server 2003

["Matthew Kidd" <matthew dot kidd at ghctechnologies dot com>]

>> I upgraded to Cygwin 1.7.1 on a (64-bit) Windows Server 2003 and
>> immediately ran into trouble. It seems that Perl can no longer
shutdown
>> pipes related to Cygwin executables. Here is some example code:
>> 
>> #!/usr/bin/perl
>> 
>> use strict;
>> 
>> # my $fname = 'Y:\path\to\ratherbigfile.gz';
>> my $fname = '/cygdrive/y/path/to/ratherbigfile.gz';
>> 
>> open(FH, "gzip -dc $fname |") || die 'open failed.';
>> for (1..4) { my $fline = <FH>; print $fline; }
>> 
>> close(FH);
>> print "done\n";
>>  
>> 
>> Before Cygwin 1.7.1 this code ran fine. It printed out four lines,
closed
>> the pipe, and exited. But now it hangs at the close(FH) statement and
the
>> child gzip process maxes out a core continuing to uncompress the big
>> file. I either have to kill the gzip process or the Perl process.
This
>> problem happens whether I use a Windows style file path or a Unix
style
>> file path. It doesn't matter if I use 32-bit or 64-bit Perl.
>> 
>> If I replace the cygwin1.dll file from the 1.7.1 installation with an
>> older version of cygwin1.dll from a different installation
(specifically
>> 1.5.25 cr-0x5f1), the code above works fine (though I imagine mixing
and
>> matching DLL version is not a good long term solution).

> Try the latest developer snapshot from http://cygwin.com/snapshots/
> fixes your problem.
>
> Corinna
>
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin
to
> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
> Red Hat

I had no luck with the 1.7.2 cygwin1.dll from the developer snapshot.
Since the 1.7.1 Cygwin package does not show this problem on a 32-bit
Windows 7 box I think it is a 64-bit architecture issue.

There is a subtle difference between the 32-bit and 64-bit Windows
architectures that might be the cause of the problem. Under 32-bit
Windows, the code above spawns a single gzip.exe child process. But on
64-bit Windows it spawns a gzip process which in turn spawns a gzip
process where the lowest level process is the one that seems to be doing
the work, i.e. is burning CPU. This behavior does not seem unique to the
Cygwin environment but rather has something to do with how Windows
handles legacy 32-bit applications in a 64-bit environment.

  - Matthew Kidd


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple