Re: Fork issues with long command lines and long $PATH
On 3/11/2011 7:22 AM, Christopher Faylor wrote: On Fri, Mar 11, 2011 at 04:33:56AM -0800, Daniel Colascione wrote: On 2/17/11 2:27 AM, Corinna Vinschen wrote: There's no way to start a process and tell the Windows loader where you want the stack. True, but there's also no requirement to use the stack provided by the loader. Why not always allocate a separate stack and switch to it early in initialization? Taking control of the stack allocation doesn't mean that you will magically be able to allocate space in the same address range in a forked process. What about using a large area of BSS as stack? -- 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
Re: Fork issues with long command lines and long $PATH
On 2/17/11 2:27 AM, Corinna Vinschen wrote: There's no way to start a process and tell the Windows loader where you want the stack. True, but there's also no requirement to use the stack provided by the loader. Why not always allocate a separate stack and switch to it early in initialization? signature.asc Description: OpenPGP digital signature
Re: Fork issues with long command lines and long $PATH
On Mar 11 04:33, Daniel Colascione wrote: On 2/17/11 2:27 AM, Corinna Vinschen wrote: There's no way to start a process and tell the Windows loader where you want the stack. True, but there's also no requirement to use the stack provided by the loader. Why not always allocate a separate stack and switch to it early in initialization? That might even work, but this, too, may be spoiled by the Windows loader if it loads another DLL prior to cygwin.dll, and that other DLL happens to use the stack area allocated by Cygwin in the parent process. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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
Re: Fork issues with long command lines and long $PATH
On Fri, Mar 11, 2011 at 04:33:56AM -0800, Daniel Colascione wrote: On 2/17/11 2:27 AM, Corinna Vinschen wrote: There's no way to start a process and tell the Windows loader where you want the stack. True, but there's also no requirement to use the stack provided by the loader. Why not always allocate a separate stack and switch to it early in initialization? Taking control of the stack allocation doesn't mean that you will magically be able to allocate space in the same address range in a forked process. -- 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
Re: Fork issues with long command lines and long $PATH
On Feb 16 12:16, Per Kristian Gjermshus wrote: The problem can be reproduced like this: Get the script http://www.smarterphone.com/cygwin/cygwin-repro and the c file http://www.smarterphone.com/cygwin/tst.c. Then compile the tst.c with gcc -o tst tst.c and put the executable in the same directory as cygwin-repro. Then run ./cygwin-repro. If everything is fine it will print ./tst stack is at 0x28cd24 and then Childs stack is at 0x28cd24. (Addresses may vary but should stay the same for each run) Then try export PATH=$PATH:$PATH to make your path longer. Repeat until forking starts failing. 0 [main] tst 4084 C:\cygwin\home\pergj\tst.exe: *** fatal error - fork: can't reserve memory for stack 0x29CB80 - 0x2A, Win32 error 487 Apparently the combination of having a very long path together with a very long command line causes the launched process (tst.exe) to get a different _tlsbase and stack location. This makes the process unable to fork() again. Thanks for the report and especially the testcase. The problem is that the stack is not created by Cygwin in the first place, and for some reason the Windows loader appears to need some more space in the low memory area below the process stack, so the process stack is moved by 64K. However, for some other reason the Windows loader doesn't move the stack from it's default location in the forked child, despite the fact that $PATH hasn't changed. The problem now is, that the memory area behind the stack is already taken, probably by same data from one of the loaded system DLLs. So Cygwin's attempt to match the child stack with the parent stack doesn't work, because it can't reserve the upper 64K of the stack space of the parent in the child. Therefore the fork failed, because it's not possible to reproduce the parent stack. Beats me why the Windows loader neglects to move the stack in the forked child even though $PATH hasn't changed. Very puzzeling. I'm not sure there's a good solution for this problem. After all, there's no way to start a process and tell the Windows loader where you want the stack. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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
