apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Misch <n...@cs.caltech.edu>
Subject Re: segfault in apr_bucket_delete
Date Sun, 23 May 2004 18:46:45 GMT
On Sat, May 22, 2004 at 04:21:02PM -0400, Cliff Woolley wrote:
> On Fri, 21 May 2004, Stas Bekman wrote:
> > I understand all that, but I guess I fail to pass the point across. It is not
> > a problem that I encounter in my code. On the contrary I'm writing tests that
> > exercise, both valid and invalid ways the API can be called. API that hangs
> > when called in invalid way is a problem. Don't you think?
> >
> The thing is, it would not be this macro that hangs.  All this macro can
> do is segfault (if one of the pointers is null, meaning the brigade was
> previously corrupted), or do what it's supposed to do (though in doing so
> it could potentially corrupt some other brigade, which is what happens
> here -- if the bucket being inserted is still in a brigade, as db is, then
> that brigade will be corrupted by this operation).  The only way to detect
> that such corruption will occur is to check the entire ring...  that's a
> linear time checking operation tacked on to a constant time insertion
> operation... not acceptable.  :)  However, if you compile with bucket
> debugging turned on, those validity checks WILL be done.

Perhaps a ``configure'' option for bucket debugging is in order?  For that
matter, why not make it the default; most folks who build their own APU do so
for a development project, so intuitive failure modes will trump efficiency in
early use.  I can roll a patch, if appropriate.

View raw message