On Tue, Nov 8, 2011 at 11:00 AM, Jeff Trawick <[email protected]> wrote:
> On Tue, Nov 8, 2011 at 9:37 AM, Jim Jagielski <[email protected]> wrote:
>> Here is the method for the Jenkins CLI that causes all the sadness.
>> The major section is this:
>
> Thanks for the testcase!
>
> The EAGAIN is getting generated from here:
>
> static apr_status_t get_remaining_chunk_line(http_ctx_t *ctx,
> apr_bucket_brigade *b,
> int linelimit)
> {
> apr_status_t rv;
> apr_off_t brigade_length;
> apr_bucket *e;
> const char *lineend;
> apr_size_t len = 0;
>
> /*
> * As the brigade b should have been requested in mode AP_MODE_GETLINE
> * all buckets in this brigade are already some type of memory
> * buckets (due to the needed scanning for LF in mode AP_MODE_GETLINE)
> * or META buckets.
> */
> rv = apr_brigade_length(b, 0, &brigade_length);
> if (rv != APR_SUCCESS) {
> return rv;
> }
> /* Sanity check. Should never happen. See above. */
> if (brigade_length == -1) {
> return APR_EGENERAL;
> }
> if (!brigade_length) {
> return APR_EAGAIN; <<<<<<<<<< here
> }
>
> Breakpoint 2, get_remaining_chunk_line (ctx=0x20061b8, b=0x2006210,
> linelimit=8190) at http_filters.c:132
> 132 return APR_EAGAIN;
> (gdb) where
> #0 get_remaining_chunk_line (ctx=0x20061b8, b=0x2006210,
> linelimit=8190) at http_filters.c:132
> #1 0x000000000046c4d6 in get_chunk_line (ctx=0x20061b8, b=0x2006210,
> linelimit=8190) at http_filters.c:213
> #2 0x000000000046cef6 in ap_http_filter (f=0x2003520, b=0x2006178,
> mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=16384)
> at http_filters.c:386
> #3 0x0000000000432ccc in ap_get_brigade (next=0x2003520,
> bb=0x2006178, mode=AP_MODE_READBYTES, block=APR_BLOCK_READ,
> readbytes=16384)
> at util_filter.c:496
> #4 0x00007facf66955e2 in ap_proxy_http_request (p=0x2001cf8,
> r=0x2001d70, p_conn=0x1f83880, worker=0x1e87190, conf=0x1e86b10,
> uri=0x2003930, url=0x20039d8 "/cgi-bin/readbody.pl",
> server_portstr=0x7faced7469c0 ":8080") at mod_proxy_http.c:1026
> #5 0x00007facf6698cfc in proxy_http_handler (r=0x2001d70,
> worker=0x1e87190, conf=0x1e86b10,
> url=0x200386e "http://127.0.0.1:8080/cgi-bin/readbody.pl";,
> proxyname=0x0, proxyport=0) at mod_proxy_http.c:2153
> #6 0x00007facf6cb9c59 in proxy_run_scheme_handler (r=0x2001d70,
> worker=0x1e87190, conf=0x1e86b10,
> url=0x200386e "http://127.0.0.1:8080/cgi-bin/readbody.pl";,
> proxyhost=0x0, proxyport=0) at mod_proxy.c:2520
> #7 0x00007facf6cb5353 in proxy_handler (r=0x2001d70) at mod_proxy.c:1055
> #8 0x000000000044efe2 in ap_run_handler (r=0x2001d70) at config.c:168
>
> At the moment I'm guessing that the chunk-specific path may be missing
> handling for unexpected EOF or some other error path.
>
> My testcase based on the Jenkins code you pasted isn't doing anything
> to provide a valid body, so there could be a difference in scenario
> which just happens to result in the same error code. We'll see.
>
I think that by the time we get here in ap_http_filter() it is all over:
@@ -365,14 +371,30 @@
rv = ap_get_brigade(f->next, bb, AP_MODE_GETLINE,
block, 0);
+ if (block == APR_BLOCK_READ &&
+ rv == APR_SUCCESS && APR_BRIGADE_EMPTY(bb)) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, f->r,
+ "No chunk line available");
+ return APR_EGENERAL;
+ }
+
/* for timeout */
if (block == APR_NONBLOCK_READ &&
( (rv == APR_SUCCESS && APR_BRIGADE_EMPTY(bb)) ||
(APR_STATUS_IS_EAGAIN(rv)) )) {
ctx->state = BODY_CHUNK_PART;
Next I need to see if I can make my version of the Jenkins testcase do
something useful and see if the behavior changes...
(Presumably the real Jenkins code is generating a valid HTTP stream.)
