apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: Debugging APR...
Date Sat, 12 Jan 2002 18:35:30 GMT
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)


Mime
View raw message