Yahoo wouldn't be chunked, would it? I suspect the httpd proxy sometimes
gets itself into a deadlock condition with the dechunk filter.
Chuck
On Thursday, August 9, 2001, at 12:22 AM, Ryan Bloom wrote:
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]
-----------------------------------------------------------------------------
