Fork failures
Ryan Johnson
ryan.johnson@cs.utoronto.ca
Sat Apr 16 00:47:00 GMT 2011
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
More information about the Cygwin-developers
mailing list