apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Debugging APR...
Date Sat, 12 Jan 2002 19:11:18 GMT
Ian Holsman <ianh@apache.org> 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>,
    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>,
    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 | trawick@attglobal.net | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message