www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: Crash in 2.0.24-dev
Date Thu, 09 Aug 2001 04:22:34 GMT

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                        	rbb@apache.org
> >> Covalent Technologies			rbb@covalent.net
> >> ------------------------------------------------------------------------
> >>-----
>
> Chuck Murcko
> Topsail Group
> http://www.topsail.org/

-- 

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------

Mime
View raw message