Re: [RFC] 3.1 branching

On Mon, 2008-09-15 at 09:21 -0400, Tsantilas Christos wrote:
> > On sΓΆn, 2008-09-14 at 16:32 -0600, Alex Rousskov wrote:
> >
> >> This is probably too vague of a statement/problem to argue about. I find
> >> the current code easier to debug, especially when new style of callbacks
> >> is used, because cache.log contains more structured information.
> >>
> >> I also need to polish and publish scripts that track/isolate a given
> >> transaction based on logged async calls.
> >
> > Yes, the AsyncCall logging is indeed easier to debug, but it's harder to
> > analyze a post-mortem crash from a core dump where you can not easily
> > reproduce the problem.
> >
> > What's primarily needed to remove this concern is to somehow dump the
> > origin where the current live call was scheduled, to be included in the
> > cache.log crash messages.
>
> Is it enough to just print the file and line where the current AsyncCall
> scheduled? I think, it can be stored in the AsyncCall object using the
> ScheduleCall.function.

Yes, it can be stored and reported without user code modifications, at
the cost of AsyncCall size increase by sizeof(int) + sizeof(char*).
There are probably 5-7 AsyncCalls per outstanding client request, on
average, but I have not verified that number. We already store debugging
section, level and handler name so it is probably OK to add two more
similar fields.

> Also there is some code in async-call branch in sourceforge which modify
> assert function to allow squid to survive from an assertion throwing an
> exception. This code was not merged (not accepted) in squid3-trunk.
> With some modications can be used to dump some debugging info about
> current AsyncCall: Instead of throw an exception just do a debugs and
> then abort.

Right. I do not know whether everybody will be comfortable with calling
[virtual] AsyncCall::print inside assert processing code as doing so
increases the risk of crashing during that call, making debugging
slightly more difficult instead of easier.

Alex.
Received on Mon Sep 15 2008 - 14:15:20 MDT