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. -- Eric Covener cove...@gmail.com
