flood reg ex matching problems
Hi folks, I grabbed flood from svn and built it according to the instructions at http://httpd.apache.org/test/flood/ I've been getting 'Regular expression match failed' most of the time, and even tried running one of the examples: -- [EMAIL PROTECTED]:/home/staff/john/flood# /usr/local/flood/bin/flood examples/round-robin-dynamic.xml Regular expression match failed (a href=([^]*)FAQ/a) postprocessing failed (http://httpd.apache.org/). Error running farmer 'Joe': Internal error. -- I even tried a ridiculously simple one and it still failed: url responsetemplate=(DOCTYPE) responsename=foohttp://httpd.apache.org/url I've even tried updating my pcre version (v3 was installed on this Ubuntu system) to no avail - it looks as though theres a version compiled in statically anyway (I'm using --disable-shared as per the doc, not sure if it has any effect on pcre). I've had some simple regex's working - eg. if I try responsetemplate=href=quot;([^quot;]+)quot; it sometimes works. Any ideas? thanks in advance, John O'Rourke
Re: apxs on Win32?
Randy Kobes wrote: On Thu, 21 Feb 2008, Guenter Knauf wrote: Hi (Bill?), another dev just asked me privately about apxs for Win32 does this meanwhile work on Win32? And if so can we perhaps ship it with future distros? I think that would make sense since the include and lib dir is already included Guenter. There's a perl script that emulates apxs on Win32 available in apxs_win32.tar.gz at http://perl.apache.org/dist/win32-bin/ Right now this is installed assuming an already-installed Apache; if there's interest, I could look at incorporating this into the build of Apache itself. +1
Re: svn commit: r629615 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_charset_lite.html.en docs/manual/mod/mod_charset_lite.xml modules/filters/mod_charset_lite.c
On Wed, Feb 20, 2008 at 4:17 PM, [EMAIL PROTECTED] wrote: Author: covener Date: Wed Feb 20 13:17:17 2008 New Revision: 629615 URL: http://svn.apache.org/viewvc?rev=629615view=rev Log: *) mod_charset_lite: Add ForceAllMimeTypes sub-option to CharsetOptions, allowing the administrator to skip the mimetype checking that precedes translation. PR 44458 [Eric Covener] What about ProcessAllMimeTypes or TranslateAllMimeTypes or something like that. Force isn't very self-descriptive. Other ideas?
Re: svn commit: r629615 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_charset_lite.html.en docs/manual/mod/mod_charset_lite.xml modules/filters/mod_charset_lite.c
On Thu, Feb 21, 2008 at 8:57 AM, Jeff Trawick [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 4:17 PM, [EMAIL PROTECTED] wrote: Author: covener Date: Wed Feb 20 13:17:17 2008 New Revision: 629615 URL: http://svn.apache.org/viewvc?rev=629615view=rev Log: *) mod_charset_lite: Add ForceAllMimeTypes sub-option to CharsetOptions, allowing the administrator to skip the mimetype checking that precedes translation. PR 44458 [Eric Covener] What about ProcessAllMimeTypes or TranslateAllMimeTypes or something like that. Force isn't very self-descriptive. Other ideas? I struggled with the option name, I'm open to TranslateAllMimeTypes. Will change and propose for backport if we don't see a better proposal this afternoon. -- Eric Covener [EMAIL PROTECTED]
Re: svn commit: r629615 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_charset_lite.html.en docs/manual/mod/mod_charset_lite.xml modules/filters/mod_charset_lite.c
On Feb 21, 2008, at 9:07 AM, Eric Covener wrote: On Thu, Feb 21, 2008 at 8:57 AM, Jeff Trawick [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 4:17 PM, [EMAIL PROTECTED] wrote: Author: covener Date: Wed Feb 20 13:17:17 2008 New Revision: 629615 URL: http://svn.apache.org/viewvc?rev=629615view=rev Log: *) mod_charset_lite: Add ForceAllMimeTypes sub-option to CharsetOptions, allowing the administrator to skip the mimetype checking that precedes translation. PR 44458 [Eric Covener] What about ProcessAllMimeTypes or TranslateAllMimeTypes or something like that. Force isn't very self-descriptive. Other ideas? I struggled with the option name, I'm open to TranslateAllMimeTypes. Will change and propose for backport if we don't see a better proposal this afternoon. +1
Re: apxs on Win32?
Hi Randy, There's a perl script that emulates apxs on Win32 available in apxs_win32.tar.gz at http://perl.apache.org/dist/win32-bin/ perfect answer since the one who asked me did that for mod_perl! Right now this is installed assuming an already-installed Apache; if there's interest, I could look at incorporating this into the build of Apache itself. lets see what Bill says - if the one we have in ./support works already with 3rd-party modules (other than mod_perl) on Win32 then we can just use that; otherwise I'm +1 to add yours. thanks, Guenter.
Re: apxs on Win32?
Guenter Knauf wrote: if the one we have in ./support works already with 3rd-party modules (other than mod_perl) on Win32 then we can just use that; otherwise I'm +1 to add yours. It does not, its crafted from libtool-junk last time I looked, and requires apr similarly provisioned (apr-config script et al). Better that we recraft Randy's work into an apr bit, and apu bit (and submit those over to apr), and either fix the libtool-specific crap in apxs.in, or use Randy's httpd bits as well. Bill
mod_proxy / ProxyTimeout fix 2.0.63
Hi Folks,
After fumbling up a previous attempt to send in this patch,
I'm going to try again, making sure to attach the patch this
time. :)
The following patch makes mod_proxy truly use ProxyTimeout
for the actual sending and receiving of the proxied request;
as it's currently implemented, it uses ProxyTimeout when
attempting the connection to the origin server *but* uses
the value of Timeout for sending and receiving the proxied
request.
Since mod_proxy introduced entirely new timeout handling in
2.2, I have not determined if this problem still exists or
is even relevant in that branch. However, I do think the
behavior in the 2.0 line at least does not match the document
for how ProxyTimeout is expected to work:
This directive allows a user to specifiy a timeout on proxy requests.
This is useful when you have a slow/buggy appserver which hangs, and
you would rather just return a timeout and fail gracefully instead of
waiting however long it takes the server to return.
Thanks,
Ron
--- modules/proxy/proxy_http.c.orig 2007-09-04 15:33:45.0 -0400
+++ modules/proxy/proxy_http.c 2008-02-21 14:20:01.0 -0500
@@ -379,6 +379,25 @@
proxy: HTTP: pre_connection setup failed (%d),
rc);
return rc;
+} else {
+// that pre_connection code sets the socket timeout as
+// the value of Timeout which is the timeout of the
+// original request; by the time that is hit, our client
+// has already been given a timeout
+//
+// instead, we'll look to see if an env var, proxy-timeout,
+// has been set: if so, we use it; otherwise, we use
+// the setting for ProxyTimeout (if set); (otherwise, we
+// will stick with the value of Timeout.)
+apr_interval_time_t timeout = (conf-timeout_set) ?
+ conf-timeout : 0;
+
+if (timeout 0) {
+apr_socket_timeout_set(p_conn-sock, timeout);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ proxy: setting request timeout (%d), timeout);
+}
+
}
}
return OK;
Re: mod_proxy / ProxyTimeout fix 2.0.63
Thanks for the patch. I'll review this as well as see if 2.2 is affected... On Feb 21, 2008, at 2:29 PM, Ronald Park wrote: Hi Folks, After fumbling up a previous attempt to send in this patch, I'm going to try again, making sure to attach the patch this time. :) The following patch makes mod_proxy truly use ProxyTimeout for the actual sending and receiving of the proxied request; as it's currently implemented, it uses ProxyTimeout when attempting the connection to the origin server *but* uses the value of Timeout for sending and receiving the proxied request. Since mod_proxy introduced entirely new timeout handling in 2.2, I have not determined if this problem still exists or is even relevant in that branch. However, I do think the behavior in the 2.0 line at least does not match the document for how ProxyTimeout is expected to work: This directive allows a user to specifiy a timeout on proxy requests. This is useful when you have a slow/buggy appserver which hangs, and you would rather just return a timeout and fail gracefully instead of waiting however long it takes the server to return. Thanks, Ron httpd-2.0.63-tproxy.patch
Re: httpd 2.2.8 segfaults
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this thing.
All coredumps I've looked at have been when serving DVD images, which of
course works flawlessly when I try it...
OK, I've been able to reproduce this, and it looks really bad because:
- I'm able to reproduce without having mod_cache loaded, ie. vanilla
httpd.
- It's as easy as continuing an aborted download, so it's a trivial
DOS.
So, to reproduce I did:
1) Download 288895 bytes of the total 577792 bytes of a DVD
image (debian-31r7-i386-binary-2.iso if you're curious).
2) Continue the download by doing wget -cS http://whatever/file.iso
This coredumps the server, immediately closing the connection to the
client.
Backtrace of coredump is:
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7cefca6 in kill () from /lib/tls/i686/cmov/libc.so.6
#2 0x08089a03 in sig_coredump (sig=11) at mpm_common.c:1235
#3 signal handler called
#4 0x in ?? ()
#5 0x08093010 in ap_byterange_filter (f=0x81606a0, bb=0x8161360)
at byterange_filter.c:271
#6 0x0808aec5 in ap_pass_brigade (next=0x81606a0, bb=0x8161360)
at util_filter.c:526
#7 0x08077576 in default_handler (r=0x815f968) at core.c:3740
#8 0x0807df8d in ap_run_handler (r=0x815f968) at config.c:157
#9 0x0807e6d7 in ap_invoke_handler (r=0x815f968) at config.c:372
#10 0x0808ea7c in ap_process_request (r=0x815f968) at http_request.c:258
#11 0x0808b543 in ap_process_http_connection (c=0x815bb08) at http_core.c:190
#12 0x08086df3 in ap_run_process_connection (c=0x815bb08) at connection.c:43
#13 0x08087274 in ap_process_connection (c=0x815bb08, csd=0x815b958)
at connection.c:178
#14 0x08094b00 in process_socket (p=0x815b920, sock=0x815b958, my_child_num=0,
my_thread_num=0, bucket_alloc=0x815d928) at worker.c:544
#15 0x080953c8 in worker_thread (thd=0x812d378, dummy=0x815b460)
at worker.c:894
#16 0xb7e87eac in dummy_worker (opaque=0x812d378)
at threadproc/unix/thread.c:142
#17 0xb7e1846b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb7d9873e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) dump_bucket ec
bucket=¨0¸(0x08161364) length=135664344 data=0x080641b0
contents=[**unknown**] rc=n/a
(gdb) print *ec
$1 = {link = {next = 0x815db00, prev = 0x8169a50}, type = 0x815d928,
length = 135664344, start = -5193905754803399840, data = 0x80641b0,
free = 0x8161390, list = 0x1}
(gdb) print *ec-type
$2 = {name = 0x815b920 ¨À\v\b0ù\025\b\030Ñ\022\b¸9\026\b\030À\025\b,
num_func = 135641240, is_metadata = APR_BUCKET_DATA, destroy = 0x816bd00,
read = 0x58, setaside = 0x815d928, split = 0x815d910, copy = 0}
(gdb) dump_brigade bb
dump of brigade 0x8161360
| type (address)| length | data addr
---
0 | FILE (0x0815db00) | 16777216 | 0x0815daa8
1 | FILE (0x0815db58) | 16777216 | 0x0815daa8
snip
265 | FILE (0x081699f8) | 16777216 | 0x0815daa8
266 | FILE (0x0815d948) | 15392768 | 0x0815daa8
267 | EOS (0x08169a50) | 0 | 0x
end of brigade
So it looks to me that the bb brigade is intact, but the ec bucket has
been smashed into bits and pieces...
This is on ubuntu710-i386, configured with:
./configure --prefix=/tmp/2.2.8.worker.debug --with-mpm=worker
--sysconfdir=/var/conf/apache2 --with-included-apr
--enable-nonportable-atomics=yes --enable-layout=GNU --with-gdbm
--without-berkeley-db --enable-mods-shared=all --enable-cache=shared
--enable-disk-cache=shared --enable-ssl=shared --enable-cgi=shared
--enable-suexec --with-suexec-caller=yada --with-suexec-uidmin=1000
--with-suexec-gidmin=1000 CFLAGS=-march=i686 -g
So, is anyone else able to reproduce this?
Any clue on what's the reason? I see some notes in CHANGES about
reusing brigades and so on, which might be related. However I'm way
too unclued to figure out even the general area of where things go
wrong in bucket-land...
I did some other tests, for example fetching 45809664 bytes of the
file and then continuing, I get this reply:
Content-Length: 103800832
Content-Range: bytes 45809664-577791/577792
Which is of course dead wrong, and using wget which trusts
Content-Length I end up with a truncated file. Talking to a
httpd-2.2.6 server I get the correct reply.
Something is really messed up in 2.2.8 (and I'm partly to blame, since
I didn't have time to test it prior to release ;)
An unrelated note: Why on earth chop the poor file into 267 buckets?
MAX_BUCKET_SIZE in srclib/apr-util/buckets/apr_brigade.c is 1GB (which
works, that's what I use with my DISKCACHE buckets), where does 16MB
come from?
/Nikke - keeping a brown paper bag handy, any takers?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---
Many
Re: httpd 2.2.8 segfaults
On Thu, Feb 21, 2008 at 1:09 PM, Niklas Edmundsson [EMAIL PROTECTED] wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this
thing.
All coredumps I've looked at have been when serving DVD images, which of
course works flawlessly when I try it...
OK, I've been able to reproduce this, and it looks really bad because:
- I'm able to reproduce without having mod_cache loaded, ie. vanilla
httpd.
- It's as easy as continuing an aborted download, so it's a trivial
DOS.
So, to reproduce I did:
1) Download 288895 bytes of the total 577792 bytes of a DVD
image (debian-31r7-i386-binary-2.iso if you're curious).
2) Continue the download by doing wget -cS http://whatever/file.iso
This coredumps the server, immediately closing the connection to the
client.
Backtrace of coredump is:
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7cefca6 in kill () from /lib/tls/i686/cmov/libc.so.6
#2 0x08089a03 in sig_coredump (sig=11) at mpm_common.c:1235
#3 signal handler called
#4 0x in ?? ()
#5 0x08093010 in ap_byterange_filter (f=0x81606a0, bb=0x8161360)
at byterange_filter.c:271
#6 0x0808aec5 in ap_pass_brigade (next=0x81606a0, bb=0x8161360)
at util_filter.c:526
#7 0x08077576 in default_handler (r=0x815f968) at core.c:3740
#8 0x0807df8d in ap_run_handler (r=0x815f968) at config.c:157
#9 0x0807e6d7 in ap_invoke_handler (r=0x815f968) at config.c:372
#10 0x0808ea7c in ap_process_request (r=0x815f968) at http_request.c:258
#11 0x0808b543 in ap_process_http_connection (c=0x815bb08) at http_core.c:190
#12 0x08086df3 in ap_run_process_connection (c=0x815bb08) at connection.c:43
#13 0x08087274 in ap_process_connection (c=0x815bb08, csd=0x815b958)
at connection.c:178
#14 0x08094b00 in process_socket (p=0x815b920, sock=0x815b958,
my_child_num=0,
my_thread_num=0, bucket_alloc=0x815d928) at worker.c:544
#15 0x080953c8 in worker_thread (thd=0x812d378, dummy=0x815b460)
at worker.c:894
#16 0xb7e87eac in dummy_worker (opaque=0x812d378)
at threadproc/unix/thread.c:142
#17 0xb7e1846b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb7d9873e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) dump_bucket ec
bucket=¨0¸(0x08161364) length=135664344 data=0x080641b0
contents=[**unknown**] rc=n/a
(gdb) print *ec
$1 = {link = {next = 0x815db00, prev = 0x8169a50}, type = 0x815d928,
length = 135664344, start = -5193905754803399840, data = 0x80641b0,
free = 0x8161390, list = 0x1}
(gdb) print *ec-type
$2 = {name = 0x815b920 ¨À\v\b0ù\025\b\030Ñ\022\b¸9\026\b\030À\025\b,
num_func = 135641240, is_metadata = APR_BUCKET_DATA, destroy = 0x816bd00,
read = 0x58, setaside = 0x815d928, split = 0x815d910, copy = 0}
(gdb) dump_brigade bb
dump of brigade 0x8161360
| type (address)| length | data addr
---
0 | FILE (0x0815db00) | 16777216 | 0x0815daa8
1 | FILE (0x0815db58) | 16777216 | 0x0815daa8
snip
265 | FILE (0x081699f8) | 16777216 | 0x0815daa8
266 | FILE (0x0815d948) | 15392768 | 0x0815daa8
267 | EOS (0x08169a50) | 0 | 0x
end of brigade
So it looks to me that the bb brigade is intact, but the ec bucket has
been smashed into bits and pieces...
This is on ubuntu710-i386, configured with:
./configure --prefix=/tmp/2.2.8.worker.debug --with-mpm=worker
--sysconfdir=/var/conf/apache2 --with-included-apr
--enable-nonportable-atomics=yes --enable-layout=GNU --with-gdbm
--without-berkeley-db --enable-mods-shared=all --enable-cache=shared
--enable-disk-cache=shared --enable-ssl=shared --enable-cgi=shared
--enable-suexec --with-suexec-caller=yada --with-suexec-uidmin=1000
--with-suexec-gidmin=1000 CFLAGS=-march=i686 -g
So, is anyone else able to reproduce this?
Any clue on what's the reason? I see some notes in CHANGES about
reusing brigades and so on, which might be related. However I'm way
too unclued to figure out even the general area of where things go
wrong in bucket-land...
I did some other tests, for example fetching 45809664 bytes of the
file and then continuing, I get this reply:
Content-Length: 103800832
Content-Range: bytes 45809664-577791/577792
Which is of course dead wrong, and using wget which trusts
Content-Length I end up with a truncated file. Talking to a
httpd-2.2.6 server I get the correct reply.
Hmm, that looks like a 32-bit cutoff.
577791 - 45809663 = 4398768128
4398768128 - 103800832 = 4294967296
4294967296 == 2^32
-B
Something is really messed up in 2.2.8 (and I'm partly to blame, since
I didn't have time to test it prior to release ;)
An unrelated note: Why on earth chop the poor file into 267 buckets?
MAX_BUCKET_SIZE in srclib/apr-util/buckets/apr_brigade.c is 1GB (which
works,
Re: httpd 2.2.8 segfaults
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce this
thing. All coredumps I've looked at have been when serving DVD images,
which of course works flawlessly when I try it...
OK, I've been able to reproduce this, and it looks really bad because:
- I'm able to reproduce without having mod_cache loaded, ie. vanilla
httpd.
- It's as easy as continuing an aborted download, so it's a trivial
DOS.
So, to reproduce I did:
1) Download 288895 bytes of the total 577792 bytes of a DVD
image (debian-31r7-i386-binary-2.iso if you're curious).
2) Continue the download by doing wget -cS http://whatever/file.iso
This coredumps the server, immediately closing the connection to the
client.
Backtrace of coredump is:
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7cefca6 in kill () from /lib/tls/i686/cmov/libc.so.6
#2 0x08089a03 in sig_coredump (sig=11) at mpm_common.c:1235
#3 signal handler called
#4 0x in ?? ()
#5 0x08093010 in ap_byterange_filter (f=0x81606a0, bb=0x8161360)
at byterange_filter.c:271
#6 0x0808aec5 in ap_pass_brigade (next=0x81606a0, bb=0x8161360)
at util_filter.c:526
#7 0x08077576 in default_handler (r=0x815f968) at core.c:3740
#8 0x0807df8d in ap_run_handler (r=0x815f968) at config.c:157
#9 0x0807e6d7 in ap_invoke_handler (r=0x815f968) at config.c:372
#10 0x0808ea7c in ap_process_request (r=0x815f968) at http_request.c:258
#11 0x0808b543 in ap_process_http_connection (c=0x815bb08) at
http_core.c:190
#12 0x08086df3 in ap_run_process_connection (c=0x815bb08) at
connection.c:43
#13 0x08087274 in ap_process_connection (c=0x815bb08, csd=0x815b958)
at connection.c:178
#14 0x08094b00 in process_socket (p=0x815b920, sock=0x815b958,
my_child_num=0,
my_thread_num=0, bucket_alloc=0x815d928) at worker.c:544
#15 0x080953c8 in worker_thread (thd=0x812d378, dummy=0x815b460)
at worker.c:894
#16 0xb7e87eac in dummy_worker (opaque=0x812d378)
at threadproc/unix/thread.c:142
#17 0xb7e1846b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb7d9873e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) dump_bucket ec
bucket=¨0¸(0x08161364) length=135664344 data=0x080641b0
contents=[**unknown**] rc=n/a
(gdb) print *ec
$1 = {link = {next = 0x815db00, prev = 0x8169a50}, type = 0x815d928,
length = 135664344, start = -5193905754803399840, data = 0x80641b0,
free = 0x8161390, list = 0x1}
Quick question:
What is shown by
- print ec
Is the 'smashed' bucket always in the same position of the brigade (e.g always
the first, second,...)
Regards
Rüdiger
Re: httpd 2.2.8 segfaults
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote: On Wed, 20 Feb 2008, Niklas Edmundsson wrote: In any case, I should probably try to figure out how to reproduce this thing. All coredumps I've looked at have been when serving DVD images, which of course works flawlessly when I try it... OK, I've been able to reproduce this, and it looks really bad because: Could you please check if backing out the following patch out of apr-util 'fixes' the problem: http://svn.apache.org/viewvc/apr/apr-util/branches/1.2.x/buckets/apr_brigade.c?r1=232557r2=588057 Regards Rüdiger
Re: httpd 2.2.8 segfaults
On 02/21/2008 10:33 PM, Ruediger Pluem wrote: On 02/21/2008 10:09 PM, Niklas Edmundsson wrote: On Wed, 20 Feb 2008, Niklas Edmundsson wrote: In any case, I should probably try to figure out how to reproduce this thing. All coredumps I've looked at have been when serving DVD images, which of course works flawlessly when I try it... OK, I've been able to reproduce this, and it looks really bad because: Could you please check if backing out the following patch out of apr-util 'fixes' the problem: http://svn.apache.org/viewvc/apr/apr-util/branches/1.2.x/buckets/apr_brigade.c?r1=232557r2=588057 Quick, maybe completely stupid question as I suspect the problem in apr_brigade_partition: I always thought that apr_off_t and apr_size_t are *always* of the same size and that the only difference between them is that apr_size_t is unsigned whereas apr_off_t is signed. Is this thought correct? Regards Rüdiger
Re: httpd 2.2.8 segfaults
On 02/21/2008 10:33 PM, Ruediger Pluem wrote:
On 02/21/2008 10:09 PM, Niklas Edmundsson wrote:
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
In any case, I should probably try to figure out how to reproduce
this thing. All coredumps I've looked at have been when serving DVD
images, which of course works flawlessly when I try it...
OK, I've been able to reproduce this, and it looks really bad because:
Could you please check if backing out the following patch out of apr-util
'fixes' the problem:
http://svn.apache.org/viewvc/apr/apr-util/branches/1.2.x/buckets/apr_brigade.c?r1=232557r2=588057
Alternatively could you give the attached patch a try. It will not work cleanly
with apr-util 1.2.x
because APR_SIZE_MAX is not defined there. So this would need to be fixed.
Regards
Rüdiger
Index: apr_brigade.c
===
--- apr_brigade.c (Revision 628865)
+++ apr_brigade.c (Arbeitskopie)
@@ -97,6 +97,7 @@
apr_bucket *e;
const char *s;
apr_size_t len;
+apr_size_t pointst;
apr_status_t rv;
if (point 0) {
@@ -108,6 +109,13 @@
return APR_SUCCESS;
}
+/*
+ * Avoid all the following casting mess: point is 0 and will not get 0
+ * in the following. So cast once and forever and move on with the casted
+ * value that is now unsigned like everything else.
+ */
+pointst = (apr_size_t)point;
+
APR_BRIGADE_CHECK_CONSISTENCY(b);
for (e = APR_BRIGADE_FIRST(b);
@@ -117,7 +125,7 @@
/* For an unknown length bucket, while 'point' is beyond the possible
* size contained in apr_size_t, read and continue...
*/
-if ((e-length == (apr_size_t)(-1)) (point APR_SIZE_MAX)) {
+if ((e-length == (apr_size_t)(-1)) (pointst APR_SIZE_MAX)) {
/* point is too far out to simply split this bucket,
* we must fix this bucket's size and keep going... */
rv = apr_bucket_read(e, s, len, APR_BLOCK_READ);
@@ -126,14 +134,14 @@
return rv;
}
}
-else if (((apr_size_t)point e-length) || (e-length == (apr_size_t)(-1))) {
+else if ((pointst e-length) || (e-length == (apr_size_t)(-1))) {
/* We already consumed buckets where point is beyond
* our interest ( point MAX_APR_SIZE_T ), above.
* Here point falls between 0 and MAX_APR_SIZE_T
* and is within this bucket, or this bucket's len
* is undefined, so now we are ready to split it.
* First try to split the bucket natively... */
-if ((rv = apr_bucket_split(e, (apr_size_t)point))
+if ((rv = apr_bucket_split(e, pointst))
!= APR_ENOTIMPL) {
*after_point = APR_BUCKET_NEXT(e);
return rv;
@@ -150,17 +158,17 @@
/* this assumes that len == e-length, which is okay because e
* might have been morphed by the apr_bucket_read() above, but
* if it was, the length would have been adjusted appropriately */
-if ((apr_size_t)point e-length) {
-rv = apr_bucket_split(e, (apr_size_t)point);
+if (pointst e-length) {
+rv = apr_bucket_split(e, pointst);
*after_point = APR_BUCKET_NEXT(e);
return rv;
}
}
-if (point == e-length) {
+if (pointst == e-length) {
*after_point = APR_BUCKET_NEXT(e);
return APR_SUCCESS;
}
-point -= e-length;
+pointst -= e-length;
}
*after_point = APR_BRIGADE_SENTINEL(b);
return APR_INCOMPLETE;
Re: httpd 2.2.8 segfaults
On Thu, 21 Feb 2008, Ruediger Pluem wrote:
Quick, maybe completely stupid question as I suspect the problem in
apr_brigade_partition:
Quick answer before I go to bed :)
I always thought that apr_off_t and apr_size_t are *always* of the
same size and that the only difference between them is that
apr_size_t is unsigned whereas apr_off_t is signed.
Is this thought correct?
No.
From my understanding, apr_size_t is what can be addressed by the
architecture, ie. on a 32bit machine it would be 32bit unsigned.
apr_off_t is the file offset, and thus not coupled to the
architecture but rather if we're LFS capable or not.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---
In case of fire, yell, FIRE You know it makes sense
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: httpd 2.2.8 segfaults
On 02/21/2008 11:59 PM, William A. Rowe, Jr. wrote: Ruediger Pluem wrote: I always thought that apr_off_t and apr_size_t are *always* of the same size and that the only difference between them is that apr_size_t is unsigned whereas apr_off_t is signed. Is this thought correct? NO NO NO no no. off_t represents an index to storage (io through FILE, fd, apr_file whatever). size_t represents an index to memory, corresponding to sizeof(void*) off = offset into externals, size = offset into our memory space. Many thanks for the clarification and just to make a complete fool of myself before I leave for bed :-): apr_off_t is always signed whereas apr_size_t is always unsigned, correct? Regards Rüdiger
Re: httpd 2.2.8 segfaults
Ruediger Pluem wrote: I always thought that apr_off_t and apr_size_t are *always* of the same size and that the only difference between them is that apr_size_t is unsigned whereas apr_off_t is signed. Is this thought correct? NO NO NO no no. off_t represents an index to storage (io through FILE, fd, apr_file whatever). size_t represents an index to memory, corresponding to sizeof(void*) off = offset into externals, size = offset into our memory space.
