This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Perl failure

I stripped down the code to a small testable bit.  The problem seems to
occur when I reach 256 forks on a cygwin1.5.18 or 19 but not on my
cygwin1.5.5. win2k system.  The original code give the forked process
time to finish,  but it still looks like it eats it after about 256
iterations  ( it actually failed between 259 and 252 iterations,  but
it's pretty complicated so I'm not sure what else was happening).

Here is my test code:
dobrin@tiburon:/tmp> cat 
#!/usr/bin/perl -w

use strict;
my $pid;

foreach my $incr (`seq 1 1 800`) {
                    unless (defined ($pid = fork)) {
                         die " cannot fork $!";
                    unless ($pid) {
                      print " the sequence is $incr \n";
             print "pid is $pid\n";


The error here is :
cannot fork Resource temporarily unavailable at ./ line 11.
panic: MUTEX_LOCK (45) [op.c:354].

On cygwin1.5.5 it finishes successfully.  I'm not sure if there is
anything else I can try,  I'm looking around for some other machines
with older cygwins on them to establish what version it stopped working

Thanks for your time

Bruce D.

-----Original Message-----
From: [] On Behalf
Of Yitzchak Scott-Thoennes
Sent: Thursday, July 13, 2006 11:06 AM
Subject: Re: Perl failure

On Thu, Jul 13, 2006 at 08:53:09AM -0700, Yitzchak Scott-Thoennes wrote:
> On Wed, Jul 12, 2006 at 05:08:43PM -0700, Bruce Dobrin wrote:
> > Hi,
> > 
> > I have a server that has been doing back end maintenance using perl 
> > on cygwin for 6 years now.  I recently upgraded from win2k and 
> > cyg1.5.9 to XP sp3 and cyg1.5.19 (to be fare,  I also cleaned up the

> > perl code a bit).  The script checks versioning and build info on 
> > about 600+ windows systems.  Since the upgrade,  it gets thru about 
> > 500 of them ( almost exactly 2 hours)  and then:
> > 
> > panic: MUTEX_LOCK (45) [util.c:2266] at 
> > /c/dist_and_install_files/source/dist2/ line 24, 
> > <HOSTFILE> line 277.
> > panic: MUTEX_LOCK (45) [op.c:354], <HOSTFILE> line 277.
> This indicates EDEADLK being returned from posix_mutex_lock.

Err, I mean pthread_mutex_lock.

Unsubscribe info:
Problem reports:

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]