Basically the original code handled -1 as a side-effect. Of course, when I re-wrote it, it wasn't exactly obvious what was going on. So, I missed the -1 case. The new code I have just tested does handle the -1 case however.
I do have some good news. The code I am about to commit will fix Proxy, however as with all good news, there is bad news. :-( I have served Google through the proxy. But, whenever I try to serve yahoo, I get nothing. I will commit what I have, and then continue to debug www.yahoo.com. Ryan On Wednesday 08 August 2001 21:14, Chuck Murcko wrote: > Hmmm, or the type of the range changed, or (god forbid) someone is using > this as a storage allocator. > > So what is it, Ryan? 8^) > > Chuck > > On Thursday, August 9, 2001, at 12:07 AM, Chuck Murcko wrote: > > Was this actually ever intended to be "legal"? I did wonder about that > > in apr_get_brigade()(in the proxy). It never segfaulted before > > though...just counted readbytes down from -1. 8^) > > > > So the brigade read routine got stricter about offset range recently? > > > > Chuck > > > > On Wednesday, August 8, 2001, at 11:52 PM, Ryan Bloom wrote: > >> I have found the bug. :-) At least, I have found the thing causing > >> the seg fault in the > >> proxy code. The problem is that the code asks for an offset of -1, > >> and the current > >> code can't handle that. I will fix that, and commit a patch. > >> > >> Jerry, can you send me the request that caused this seg fault? > >> > >> Ryan > >> > >> On Wednesday 08 August 2001 17:02, Jerry Baker wrote: > >>> I haven't been able to pin down what causes this crash, but it just > >>> seems to happen at random times. There are no accesses in the log > >>> that coincide with the crashes that I can tell. > >>> > >>> apr_brigade_split(apr_bucket_brigade * 0x005651b8, apr_bucket * > >>> 0x0059b248) > >>> line 124 + 11 bytes ap_http_filter(ap_filter_t * 0x00562ca8, > >>> apr_bucket_brigade * 0x005651b8, int 0, __int64 * 0x00564ac8) line > >>> 661 + 14 > >>> bytes ap_get_brigade(ap_filter_t * 0x00562ca8, apr_bucket_brigade * > >>> 0x005651b8, int 0, __int64 * 0x00564ac8) line 217 + 24 bytes > >>> ap_get_client_block(request_rec * 0x00564a38, char * 0x100ddc50, > >>> unsigned > >>> int 8192) line 1483 + 31 bytes ap_discard_request_body(request_rec * > >>> 0x00564a38) line 1572 + 21 bytes ap_die(int 301, request_rec * > >>> 0x00564a38) > >>> line 180 > >>> decl_die(int 301, char * 0x6ff4e4a4 `string', request_rec * > >>> 0x00564a38) > >>> line 239 process_request_internal(request_rec * 0x00564a38) line > >>> 262 + 18 > >>> bytes ap_process_request(request_rec * 0x00564a38) line 444 + 9 bytes > >>> ap_process_http_connection(conn_rec * 0x00562aa8) line 287 + 9 bytes > >>> ap_run_process_connection(conn_rec * 0x00562aa8) line 82 + 81 bytes > >>> ap_process_connection(conn_rec * 0x00562aa8) line 221 > >>> worker_main(int 249) line 908 > >>> _threadstartex(void * 0x0059b248) line 212 + 13 bytes > >>> KERNEL32! 77e8758a() > >> > >> -- > >> > >> ________________________________________________________________________ > >>_____ Ryan Bloom [EMAIL PROTECTED] > >> Covalent Technologies [EMAIL PROTECTED] > >> ------------------------------------------------------------------------ > >>----- > > Chuck Murcko > Topsail Group > http://www.topsail.org/ -- _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
