[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Parallel Bug Reports Work-around for stackdump on cygwin

From: John Marter
Subject: Re: GNU Parallel Bug Reports Work-around for stackdump on cygwin
Date: Thu, 15 Aug 2013 07:22:03 -0500

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Ole Tange

On Wed, Aug 14, 2013 at 8:03 PM, John Marter <address@hidden> wrote:

> I don't imagine that this is a very useful general patch that will 
> ever get applied, but it did fix the problem I have with /bin/true 
> version 8.15-1 on Cygwin.  Since I upgraded yesterday, every time I 
> run parallel, I get a

What did you upgrade? Cygwin or Parallel?

> true.exe.stackdump left in the directory.

That sounds very odd. Removing the stackdump seems like a workaround not fixing 
the root cause.

GNU Parallel uses the command 'true' to figure out the maximal command line 
size. I do not have access to a cygwin environment, so can you

true x
true [insert 10000 x here]
true [insert 100000 x here]
true [insert 300000 x here]

Do any of these cause a stackdump?


Hi Ole,

I agree it is a work-around, and I had upgraded Cygwin the day before so it is 
ultimately something that needs to be fixed in true, but the Perl source of 
Parallel was something I could tackle right away.

This will cause true to crash (Note the full path to avoid the bash builtin).

/bin/true $(perl -e 'print "x"x6291448')

This will not cause a crash.

/bin/true $(perl -e 'print "x"x6291447')

I found the number with "parallel --show-limits".  I suspect that the crash 
causes parallel to choose a smaller number for that limit than it otherwise 
would have, but it doesn't seem to be a problem, I seem to remember seeing an 
internal max of 8_000_000 so it gets pretty close.

I did notice an interesting performance issue here, but I have not fully 
investigated it.  I ran the following command.

time parallel --show-limits echo ::: 1

On a Linux system it found a maximal size of 131071 and ran in 0.421 seconds.  
On my Cygwin system the same command took 12.543 seconds.   The systems have 
rather different performance characteristics, so a direct comparison is not 
easy, but I thought I would look at it closer after Cygwin fixes their "true" 
problem (I will be reporting that to them this morning).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]