On Thu, 2002-12-19 at 20:46, Cliff Woolley wrote: > On Thu, 19 Dec 2002, Cliff Woolley wrote: > > > > HEAD (as of sometime yesterday) is segfaulting on me. Stack trace below. > > > This happens on all SSL requests; others seem fine. This on Linux with > > > RedHat's openssl-0.9.6b-28. > > > > Sigh. Wonder if this is related to what FirstBill saw earlier today with > > the proxy? Seeing as nothing has changed in the buckets code any time > > recently... OHHHHHHHH WAIT, yes it has. Brian apparently committed a > > change to allocate the apr_bucket_brigade itself out of the brigade > > allocator. I'm not yet convinced whether that's valid or not, but > > regardless, that change (either a bug in it or a flaw elsewhere that it > > triggered) is almost certain to be what's triggered these segfaults. > > I'm not sure yet, but it's quite likely that what's happening is that the > modules that are now broken are destroying a brigade and then reusing it > anyway. Those modules should be using apr_brigade_cleanup() rather than > apr_brigade_destroy(). [This would have been considered a bug in those > modules all along, but it wouldn't necessarily have caused a segfault > before, whereas it definitely would now.]
That makes sense. One way to find out for sure would be to replace the bucket_alloc/_free in my latest code with malloc/free. This would take the bucket allocator out of the equation. If you still get the segfault using malloc/free, then I'd be pretty confident that the problem is indeed due to code using an already-destroyed brigade. > I don't see any particular problems in Brian's patch itself. Though > having b->p be potentially NULL worries me... I can't find anything that > that would break yet, but I'll keep my eyes open. I don't think b->p will be null in any current usage of the code. I put in support for the b->p==NULL case in order to support some use cases that I think may be important in future async MPMs. Brian
