OK to add _STRACE_FORK category?
Tue May 10 16:47:00 GMT 2011
On Tue, May 10, 2011 at 09:32:17AM -0400, Ryan Johnson wrote:
>On 10/05/2011 6:09 AM, Corinna Vinschen wrote:
>> On May 4 15:33, Ryan Johnson wrote:
>>> 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
>> I just noticed that I never replied. Please use sigproc_printf and
>> debug_printf. However, fork has already a lot of strace output, so
>> it would be favorable to keep the number of extra printfs as small
>> as possible. Maybe there are even some we should remove.
>As for the quantity of output, I'm torn. Whenever Windows throws a new
>curveball at fork() the first step will always be to figure out what new
>thing went wrong (or what existing thing is suddenly going wrong more
>often), and I've added special_printf calls which expose this
>information in a fair amount of detail. Problem is, AFAICT *_printf
>calls execute fully whenever strace is active, with strace performing
>the filtering on its side. This means a lot of unwanted overhead most of
>the time. Perhaps I should leave the calls there, with an #ifdef
>(DEBUGGING?) so future developers don't have to reinvent the wheel next
No. You're basically asking for a special *_printf() function just for
yourself. We don't want to litter fork with your debugging attempts.
More information about the Cygwin-developers