Re: Fork failures

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

On 15/04/2011 9:42 AM, Christopher Faylor wrote:
> being able
> to build the DLL and find things in the source is a prerequisite for
> contributing to discussions here.

A fitting start:

$ make
make[1]: Entering directory `/home/Ryan/apps/cygwin-src'
Configuring in ./etc
/home/Ryan/apps/cygwin-src/etc/configure: fork: retry: Resource 
temporarily unavailable
/home/Ryan/apps/cygwin-src/etc/configure: fork: retry: Resource 
temporarily unavailable
/home/Ryan/apps/cygwin-src/etc/configure: fork: retry: Resource 
temporarily unavailable
/home/Ryan/apps/cygwin-src/etc/configure: fork: retry: Resource 
temporarily unavailable
/home/Ryan/apps/cygwin-src/etc/configure: fork: Resource temporarily 
unavailable

Hopefully it will at least make a reproducible test case to work with...

Fork failures aside, I have actually built the dll and .dbg to go with 
it. The real problem has been getting a debugger to be helpful. When I 
run my fork test with the error_debug script from 
how-to-debug-cygwin.txt, the access violation dutifully fires up gdb, 
but the latter is unable to break in; fork-test.exe spikes to 100% cpu 
utilization and stays that way even after I kill gdb. Windbg can attach, 
but the call stack it reports is all inside ntdll. Running fork-test.exe 
with a getch(), then attaching windbg -- with '.childdbg 1' -- can trap 
the exception, but  it's slow going with no debug symbols to help (it 
doesn't even get function names right).

Everything works as advertized for a toy program that purposefully seg 
faults, which make me worry that it's just too early in cygwin's startup 
for gdb to talk to it. Is there some better way I missed?

Ryan