Cool info… I'm (painfully) building Jenkins here locally and will try to get a bt on the actual scenario…
On Nov 8, 2011, at 11:00 AM, Jeff Trawick 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. >
