Thanks
I have the feeling that you catched some which solves a lot of
reported crashes since 2.4.17.
Running now with 2.4.32, now waiting is we have still crashes.
Only rebuild libhttpd.dll with request.c :
* It is still safe to use r / r->pool here as the eor
bucket
* could not have been destroyed in the event of a
timeout.
*/
ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c,
APLOGNO(01581)
"flushing data to the client");
}
}
if (ap_extended_status) {
ap_time_process_request(c->sbh, STOP_PREQUEST);
}
On Monday 12/03/2018 at 13:03, Yann Ylavic wrote:
On Mon, Mar 12, 2018 at 12:53 PM, Yann Ylavic <ylavic....@gmail.com>
wrote:
Can you still reproduce with this patch:
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 1826315)
+++ modules/http/http_request.c (working copy)
@@ -470,7 +470,7 @@ AP_DECLARE(void) ap_process_request(request_rec *r
ap_process_async_request(r);
- if (!c->data_in_input_filters) {
+ if (!c->data_in_input_filters && !c->aborted) {
bb = apr_brigade_create(c->pool, c->bucket_alloc);
b = apr_bucket_flush_create(c->bucket_alloc);
APR_BRIGADE_INSERT_HEAD(bb, b);
?
Hmm, no, nevermind, ap_pass_brigade() won't return APR_TIMEOUT if
c->aborted already.
The fix could be something like this:
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 1826315)
+++ modules/http/http_request.c (working copy)
@@ -484,9 +484,8 @@ AP_DECLARE(void) ap_process_request(request_rec *r
* It is still safe to use r / r->pool here
as the eor bucket
* could not have been destroyed in the
event of a timeout.
*/
- ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r,
APLOGNO(01581)
- "Timeout while writing data for URI %s to
the"
- " client", r->unparsed_uri);
+ ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c,
APLOGNO(01581)
+ "flushing data to the client");
}
}
if (ap_extended_status) {
_
Would you test if it works for you?
