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]

Fork issues with long command lines and long $PATH

We have had recurring problems where some of our machines suddenly fail to be able to compile our software. We are using a make based build system and in certain cases we end up with very long command lines to the linker.

Initially we observed the issue on Windows 7 machines and basically tried everything including clean re-install, checking the bloda list, rebaseall and so on and so forth. The problem would suddenly manifest itself with no apparent reason.

We therefore decided to spend the time needed to get to the bottom of this and with the reproduction steps below the problem can be reproduced on Windows XP as well.

The problem can be reproduced like this:

Get the script and the c file 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 - 0x2A0000, 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.

In the failing cases child_info_fork::alloc_stack _tlsbase is compared with stackbottom and alloc_stack_hard_way is called. The first VirtualAlloc then always fails.

At this time we don't know if the fix should be in alloc_stack_hard_way or if it should be to make sure that _tlsbase and stackbottom are always the same.

Per Kristian

Attachment: cygcheck.out
Description: Text document

Problem reports:
Unsubscribe info:

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