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.
