You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jerry Baker <je...@weirdness.com> on 2001/08/09 02:02:40 UTC

Crash in 2.0.24-dev

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()

-- 
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 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/

Re: Crash in 2.0.24-dev

Posted by Ryan Bloom <rb...@covalent.net>.
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 Ryan Bloom <rb...@covalent.net>.
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 Ryan Bloom <rb...@covalent.net>.
This is most likely related to the patches I have put into that filter today.  I am still trying
to track down what is going on.

Ryan

On Wednesday 08 August 2001 17:48, Jerry Baker wrote:
> Cliff Woolley wrote:
> > Does this happen with the 2.0.23 tag or not?
> >
> > Thanks,
> > Cliff
> >
> > --------------------------------------------------------------
> >    Cliff Woolley
> >    cliffwoolley@yahoo.com
> >    Charlottesville, VA
>
> Not that I am aware of, but I haven't let it sit and run for awhile.
> I'll try it. If you hear nothing from me assume it's ok.

-- 

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

Re: Crash in 2.0.24-dev

Posted by Jerry Baker <je...@weirdness.com>.
Cliff Woolley wrote:
> 
> On Wed, 8 Aug 2001, Jerry Baker wrote:
> 
> > Not that I am aware of, but I haven't let it sit and run for awhile.
> > I'll try it. If you hear nothing from me assume it's ok.
> 
> Okay, thanks.  Second question: are you running on the absolute most
> current CVS?  In particular, I'm wondering if you're running with Ryan's
> most recent patch or without.
> 
> Thanks,
> Cliff
> 
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA

I had pulled the CVS at about 5:00pm MDT or so.

-- 
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 Cliff Woolley <cl...@yahoo.com>.
On Wed, 8 Aug 2001, Jerry Baker wrote:

> Not that I am aware of, but I haven't let it sit and run for awhile.
> I'll try it. If you hear nothing from me assume it's ok.

Okay, thanks.  Second question: are you running on the absolute most
current CVS?  In particular, I'm wondering if you're running with Ryan's
most recent patch or without.

Thanks,
Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Re: Crash in 2.0.24-dev

Posted by Jerry Baker <je...@weirdness.com>.
Cliff Woolley wrote:
> 
> Does this happen with the 2.0.23 tag or not?
> 
> Thanks,
> Cliff
> 
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA

Not that I am aware of, but I haven't let it sit and run for awhile.
I'll try it. If you hear nothing from me assume it's ok.

-- 
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 Cliff Woolley <cl...@yahoo.com>.
On Wed, 8 Aug 2001, 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()

Does this happen with the 2.0.23 tag or not?

Thanks,
Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA