Re: OK to add _STRACE_FORK category?

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

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