On Mon, Mar 12, 2018 at 4:50 PM, Eric Covener <cove...@gmail.com> wrote:
> On Mon, Mar 12, 2018 at 11:37 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
>> On Mon, Mar 12, 2018 at 3:09 PM, Eric Covener <cove...@gmail.com> wrote:
>>> On Mon, Mar 12, 2018 at 9:42 AM, Rainer Jung <rainer.j...@kippdata.de> 
>>> wrote:
>>>> Hi Steffen, hi list,
>>>> Am 12.03.2018 um 14:07 schrieb Steffen:
>>>>> I think it should released with 2.4.32 (+) .
>>>>> Endly  solved  a pain with  all that crashes.
>>>> thanks for reminding us of that problem.
>>>> Since it is a logging only change for INFO log level and our default log
>>>> level is WARN, plus as far as I understand you it is not a regression, I
>>>> would personally tend to not rate this as a showstopper.
>>> I wonder if the C99 macro expansion for rerror was also technically
>>> risky even w/ WARN?
>> I think we have the same issue at macro expansion time than at
>> potential/external "error_log" hook, we can't dereference 'r' from
>> ap_process_async_request() in any case.
>> So this might happen with vanilla httpd too (modulo pool recycling/cache...).
> Maybe a queryable,  mpm_common way of deferring the
> clear/destroy/whatever of the request pool? I don't the best grip on
> the whole EOR thing.

Nope, EOR bucket really destroys r->pool, MPMs handle c->pool.

Reply via email to