This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: make, PATH & "Win32 error 487"
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 23 May 2013 18:07:11 +0200
- Subject: Re: make, PATH & "Win32 error 487"
- References: <alpine dot LFD dot 2 dot 03 dot 1305230950500 dot 1918 at mcs dot anl dot gov>
- Reply-to: cygwin at cygwin dot com
On May 23 10:14, Satish Balay wrote:
> Hi,
>
> I'm seeing the following behavior with make, PATH on cygwin. Google
> brought up a related post [with PATH and same error]
> http://comments.gmane.org/gmane.os.cygwin/137168 with reference to
> http://cygwin.com/acronyms/#BLODA as the issue - but I don't
> understand how this would apply to this case. Hence this post.
>
> Attaching a makefile that demonstrates this problem. The following are
> my observations.
>
> - The breakage is observable - when I have 2 commands invoked via 'make'
> either as 'cmd1|cmd2' or 'cmd1; cmd2'. The same command executed directly
> by a shell script runs fine. Or single command from make runs fine as well.
> - It appears to be related to the huge length of one of the commands - and
> length of PATH
> - I tried it on 3 different machines [with differences in default installed software]
> win2008/x64 - breaks when PATH is over 1.5K chars
> win2003/x32 - breaks when PATH is over 2K chars
> win7/x32 - breaks when PATH is over 20K chars.
>
> Any ideas on how to debug this further to better understand the issue
> - or workarrounds? This is with latest cygwin [and rebaseall done
> correctly]
There's perhaps not much you can do. First of all, the problem is known
for a while, but even though we're trying a lot of stuff to make sure
that fork works, the OS has some funny notions sometimes, which make it
hard to get fork 100% reliable.
In this case, there's a subtil difference between the first shell
started from make, and a forked subshell. The difference is something
to do with the size of $PATH which results in a different position of
the main stack in the forked child process. This breaks fork because
fork semantics require to be able to reproduce the parent memory in the
child process.
Thanks for the test case. I'm just investigating what happens exactly,
and I have a few ideas how we can workaround this problem to make fork
a bit more reliable in this situation. This requires some fiddling
around, so, just stay tuned for a couple of days.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
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