apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: segfault in apr_bucket_delete
Date Sat, 22 May 2004 03:43:05 GMT
Cliff Woolley wrote:
> On Fri, 21 May 2004, Stas Bekman wrote:
> 
> 
>>Joe Orton wrote:
>>
>>>On Thu, May 20, 2004 at 03:54:58PM -0700, Stas Bekman wrote:
>>>
>>>
>>>>       fb = apr_bucket_flush_create(ba);
>>>>       db = apr_bucket_transient_create("aaa", 3, ba);
>>>>       APR_BRIGADE_INSERT_HEAD(bb, db);
>>>>       APR_BUCKET_INSERT_BEFORE(fb, db);
>>>
>>>The arguments to APR_BUCKET_INSERT_BEFORE are reversed, right? It works
>>>for me with the arguments switched.
>>
>>right, but why does it hang when reversed.
> 
> 
> APR_BUCKET_INSERT_BEFORE(fb, db) expands to something like:
> 
>     APR_BUCKET_NEXT(db) = fb;
>     APR_BUCKET_PREV(db) = APR_BUCKET_PREV(fb);
>     APR_BUCKET_NEXT(APR_BUCKET_PREV(fb)) = db;
>     APR_BUCKET_PREV(fb) = db;
> 
> Obviously for this to work, all that has to happen is that fb's prev
> pointer and the next pointer of that bucket must correctly point to each
> other.  Everything else is arbitrarily overwritten.  Did you try running
> this with bucket debugging turned on like I suggested?  If you do that,
> then a bunch of ring consistency checks will be run for you at strategic
> times that might help you discern when it is that your brigade gets
> corrupted.
> 
> 
>>Shouldn't it work both ways? If
>>not, then it should produce an error and not hang.
> 
> 
> No... it's just a macro manipulating some pointers.  Error handling would
> be difficult (given the number of layers of macros) and expensive.

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?

   APR_BUCKET_INSERT_BEFORE(fb, db);

is not the most intuitive API, and it's very easy to mix the arguments (since 
both are of the same type). I have to pause every time and think hard to see 
whether I've got it right.

Granted, if I was passing NULL or a corrupted reference and getting a 
segfault, then it'll be my problem. But how do you suggest that we protect 
users from doing mistakes and more important how do we point out those 
mistakes in the error message and not having each user submit a bug report, us 
waste hours trying to understand what the problem is, just to discover that 
the user got the arguments in the wrong order.

I suppose if APR doesn't do validation, we will be forced to write wrappers 
which will do the validation :( I understand that this validation may slow 
things down and therefore an undesired thing. I'm not sure what's the happy 
compromise here.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message