You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modproxy-dev@apache.org by Ryan Bloom <rb...@covalent.net> on 2001/08/09 05:52:26 UTC
Re: Crash in 2.0.24-dev
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
-----------------------------------------------------------------------------
Re: Crash in 2.0.24-dev
Posted by Jerry Baker <je...@weirdness.com>.
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
I believe it was a code red scan. That's all that is in the access logs
around that time though. Not sure if the request was logged before the
crash occured.
--
Jerry Baker
PGP Key: http://www.jerrybaker.org/pgp.html
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: Crash in 2.0.24-dev
Posted by Chuck Murcko <ch...@topsail.org>.
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/
>
Re: Crash in 2.0.24-dev
Posted by Chuck Murcko <ch...@topsail.org>.
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/
Re: Crash in 2.0.24-dev
Posted by Chuck Murcko <ch...@topsail.org>.
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/