OK to add _STRACE_FORK category?

Ryan Johnson ryan.johnson@cs.utoronto.ca
Tue May 10 17:41:00 GMT 2011

On 10/05/2011 12:46 PM, Christopher Faylor wrote:
> 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.
>> sigproc_printf: ack.
>> 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
>> time around?
> No.  You're basically asking for a special *_printf() function just for
> yourself.  We don't want to litter fork with your debugging attempts.
The patch was offered in the hope that it would make others' lives 
easier. I track my debugging attempts in a local hg repository and will 
not be affected either way. *shrugs*


More information about the Cygwin-developers mailing list