(gdb) p alloc_sz $3 = 0
Bingo. That's the problem. I've checked in a fix for this and have uploaded a new snapshot. Can you confirm that it fixes the problem?
Yep, fixes my little test case. I'll run more exhaustive tests tomorrow.
It handled my real-world case well, but when I increased the stress level, I ran into a problem (the following is on my wife's beefy winXP machine, same one as before):
Running two toolchain builds in parallel, both in the background, and with tail -f in the foreground, I pressed ^C to kill the tail -f, and one of the toolchain builds aborted with the message:
C:\cygwin\opt\crosstool\powerpc-860-linux-gnu\gcc-3.3.3-glibc-2.3.2\lib\gcc-lib\
powerpc-860-linux-gnu\3.3.3\collect2.exe (684): *** fork: can't reserve memory for stack 0x30000 - 0x230000, Win32 error 487
5 [main] collect2 2932 sync_with_child: child 684(0x6EC) died before initialization with status code 0x1
Sounds rather like some stress testing is in order, but I don't know if it should hold up your next release.
One further observation: on winMe, you can only open a dozen or so /dev/null fds in a single process before open starts returning -1. Shouldn't matter, but it is strange.
- Dan
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
