Ian Holsman <[EMAIL PROTECTED]> writes:
> David Reid wrote:
>
> > Following on from Sander & Ian's work on adding debug code to the pools, is
> > there any reason this can't be extended across to APR in general? Jeff has
> > recently posted to httpd about a problem he's been having and has a patch
> > that he doesn't really want to go into APR for adding some interesting
> > debugging, but really the problem is more complex than that isn't it?
> > We should have some way of getting OS relevant debugging information
> > out
> > from APR for hte various "sub" sections, probably along the same lines as
> > the pool debug stuff just committed. I say OS relevant as there's no point
> > having general output where we differ so wildly in the types of certain key
> > things we'd want to see (fd == int on unix, handle on win32 and so on).
> > If we agree then shall we start with one particular section, say
> > network_io
> > as this is potentially one of our biggest and most problematic areas?
> > david
> >
>
> I suggested something very similiar to what was done on the pool
> code to be applied to the bucket code. I think the general feeling
> was that people didn't like the #ifdefs everywhere. (cliff also mentioned
> it would be better to track the bridage movement not creation)
>
> I'm +1 for the idea on brigade, and pools ops as I think they
> are difficult to get correct for a module developer not intimate with
> the library.
>
> I think the network/file I/O should be done, but this should be at a different
> debug level for the library developers to use, possibly even with a 'replay'
> function
> which could re-read the output file and play it back through the original
> application
> so you could playback a segfault/incorrect (or is that WAY too hard)
For brigade operations, a filter you can stick between other filters
can give you a lot of information.
Something like this would let you do all sorts of stuff, debug or not, without
cluttering APR:
apr_socket_push_op(mysock, myrecv, myuserdata, APR_SOCKET_RECV);
struct apr_recv_fns {
struct apr_recv_fns *next;
void *userdata;
apr_recv_t *fn;
};
/* this gets called on every socket recv operation */
apr_status_t myrecv( <regular apr_socket_recv parameters here>,
apr_recv_fns *this)
{
apr_status_t rv;
rv = this->next->fn(<regular apr_socket_recv parms>,
this->next);
if (rv == APR_SUCCESS) {
trace_data(this->userdata, buffer, buflen);
}
return rv;
}
here's another use for something other than debugging...
apr_status_t myrecv( <regular apr_socket_recv parameters here>,
void *userdata, apr_recv_fns *next)
{
apr_status_t rv;
rv = this->next->fn(<regular apr_socket_recv parms>,
this->next);
if (rv == APR_SUCCESS) {
/* yeah, we really need to piece together data read on
* multiple recvs, but you get the picture
*/
if (strstr(buffer, "/system32/cmd.exe")) { /* some stupid worm */
/* make Apache see dropped connection */
return APR_EOF;
}
}
return rv;
}
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
