OK to add _STRACE_FORK category?

Ryan Johnson ryan.johnson@cs.utoronto.ca
Wed May 4 19:33:00 GMT 2011

Hi all,

I'm currently producing sending quite a bit of information to 
special_printf while forking, and suspect that at least some of it would 
be good to leave in place. Further, I think it would make sense to have 
a fork category for strace so that people trying to diagnose fork 
problems have a way to figure out what's going wrong without having to 
slog through strace's all/debug output:

         thread   0x040000 (_STRACE_THREAD)   Thread-locking calls.
+       fork     0x080000 (_STRACE_FORK)     Fork-related information.
         special  0x100000 (_STRACE_SPECIAL)  Special debugging printfs for
                                              non-checked-in code

If folks are all right seeing an _STRACE_FORK appear, I'll add that to 
my code before submitting a patch and cgf or somebody can decide which 
fork_printf calls to actually keep. Otherwise, I'll submit a patch 
containing special_printf calls and solicit input on which categories 
the "keepers" should live in.

I would actually like to see api_fatal calls from a child process 
diverted to strace_printf if in_forkee=1, since they're quite annoying 
to the user and not usually helpful, but that's a separate discussion. 
For now I have a "fork_api_fatal" call which triggers a clean exit of 
the child, to be used in cases where we know exactly what's wrong but 
can't do anything about it. So far there are three such cases:
(a) static dll mapped to wrong address in the child (no way to unload it 
and retry)
(b) space needed for a dynamic dll already occupied (thread stack, heap, 
(c) failure to allocate the child's cygheap

Note that in all three cases, the underlying cause is usually (b).


More information about the Cygwin-developers mailing list