[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
try:
true x
true [insert 10000 x here]
true [insert 100000 x here]
true [insert 300000 x here]
Do any of these cause a stackdump?
/Ole
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).
-John