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*
Ryan
More information about the Cygwin-developers
mailing list