That's what I worried...
I applied Justin's patch, so far so good. So this is the fix we'll use.
BTW, by APR_BUCKET_INSERT_TAIL, I think you mean APR_BRIGADE_INSERT_TAIL
Thanks,
-- Jin
Brian Pane wrote:
>
> Justin Erenkrantz wrote:
>
> >On Fri, Dec 14, 2001 at 09:32:11AM -0800, Ian Holsman w
On Fri, Dec 14, 2001 at 04:44:26PM -0800, Brian Pane wrote:
> Thanks, this patch seems to fix the problem. One question,
> though: why remove the bucket and then insert it at the end
> of the same brigade? Is that just in case there's an EOS in
> the middle of the brigade?
Oh, yeah, the EOS is
On Fri, 14 Dec 2001, Brian Pane wrote:
> Thanks, this patch seems to fix the problem. One question,
> though: why remove the bucket and then insert it at the end
> of the same brigade? Is that just in case there's an EOS in
> the middle of the brigade?
EOS buckets aren't allowed in the middle
Justin Erenkrantz wrote:
>So, I'm thinking the appropriate check is to stop at EOS or
>SENTINEL. There is no good reason to continue processing if we
>see an EOS. But, we have a potentially saved brigade to handle.
>So, what do we do? Perhaps this patch might be better:
>
>Index: modules/fil
Brian Pane wrote:
> I haven't had time to read through through Justin's patch in detail,
> but conceptually I think it's the right approach: check for the EOS
> condition as a special case in the end-of-brigade code that's crashing,
> rather than resetting the state every time we enter the filt
Justin Erenkrantz wrote:
>On Fri, Dec 14, 2001 at 09:32:11AM -0800, Ian Holsman wrote:
>
>>hi guys.
>>we've been investigating a couple of core dumps in some testing and we
>>think we found one in mod-include.
>>
>>here is the email thread.
>>does anyone have any reason NOT to reset the state wh
On Fri, Dec 14, 2001 at 09:32:11AM -0800, Ian Holsman wrote:
> hi guys.
> we've been investigating a couple of core dumps in some testing and we
> think we found one in mod-include.
>
> here is the email thread.
> does anyone have any reason NOT to reset the state when reseting
> the bytes parse
hi guys.
we've been investigating a couple of core dumps in some testing and we
think we found one in mod-include.
here is the email thread.
does anyone have any reason NOT to reset the state when reseting
the bytes parsed ?
It seems to fix this problem, but I'm fearful that it will cause
some
