This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
OK to add _STRACE_FORK category?
- From: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 04 May 2011 15:33:01 -0400
- Subject: OK to add _STRACE_FORK category?
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,
locale.nls...)
(c) failure to allocate the child's cygheap
Note that in all three cases, the underlying cause is usually (b).
Thoughts?
Ryan