You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Striker <st...@apache.org> on 2003/09/10 13:12:46 UTC
Tagged 2.0
Hi,
I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've
put some tarballs containing that tag up at:
http://www.apache.org/~striker/httpd-2.0.48-pre2/
Testers, please test this release candidate.
Thanks!
Sander
NB: I'll lay the final tag once the release candidate proves
to be ok. This also includes bumping the version numbers
to their final state (read: minus -dev).
RE: Tagged 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Sunday, September 28, 2003 2:44 AM
[...]
> Ok, I've tagged pre3. I consider this the last tag and I'd like to
> turn that into the next 2.0 release.
Due to the received feedback I had to do a pre4 tag (STRIKER_2_0_48_PRE4).
Tarballs are up at:
http://www.apache.org/~striker/httpd-2.0.48-pre4/.
Please give it a whirl. I'd really like to get this release out of
the door.
Sander
RE: Tagged 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Sunday, September 28, 2003 2:44 AM
[...]
> Ok, I've tagged pre3. I consider this the last tag and I'd like to
> turn that into the next 2.0 release.
Due to the received feedback I had to do a pre4 tag (STRIKER_2_0_48_PRE4).
Tarballs are up at:
http://www.apache.org/~striker/httpd-2.0.48-pre4/.
Please give it a whirl. I'd really like to get this release out of
the door.
Sander
RE: Tagged 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Sunday, September 28, 2003 2:44 AM
[...]
> Ok, I've tagged pre3. I consider this the last tag and I'd like to
> turn that into the next 2.0 release.
Due to the received feedback I had to do a pre4 tag (STRIKER_2_0_48_PRE4).
Tarballs are up at:
http://www.apache.org/~striker/httpd-2.0.48-pre4/.
Please give it a whirl. I'd really like to get this release out of
the door.
Sander
RE: Tagged 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Wednesday, September 17, 2003 2:24 PM
> Tell you what, if I see those merges start trickling in, I'll hold the
> pre3 tag til friday. We'll put the thing on minotaur directly, and
> announce to stable-testers. I'm hoping we can get enough +1s around
> tuesday/wednesday to push out the final release.
Ok, I've tagged pre3. I consider this the last tag and I'd like to
turn that into the next 2.0 release.
Testing tarballs are up at:
http://www.apache.org/~striker/httpd-2.0.48-pre3/
> I haven't been pushing this release hard enough. It's dragging
> on way too long... Sorry about that.
I guess I didn't really make a difference last week...
Sander
RE: Tagged 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Wednesday, September 17, 2003 2:24 PM
> Tell you what, if I see those merges start trickling in, I'll hold the
> pre3 tag til friday. We'll put the thing on minotaur directly, and
> announce to stable-testers. I'm hoping we can get enough +1s around
> tuesday/wednesday to push out the final release.
Ok, I've tagged pre3. I consider this the last tag and I'd like to
turn that into the next 2.0 release.
Testing tarballs are up at:
http://www.apache.org/~striker/httpd-2.0.48-pre3/
> I haven't been pushing this release hard enough. It's dragging
> on way too long... Sorry about that.
I guess I didn't really make a difference last week...
Sander
RE: Tagged 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Sander Striker [mailto:striker@apache.org]
> Sent: Wednesday, September 17, 2003 2:24 PM
> Tell you what, if I see those merges start trickling in, I'll hold the
> pre3 tag til friday. We'll put the thing on minotaur directly, and
> announce to stable-testers. I'm hoping we can get enough +1s around
> tuesday/wednesday to push out the final release.
Ok, I've tagged pre3. I consider this the last tag and I'd like to
turn that into the next 2.0 release.
Testing tarballs are up at:
http://www.apache.org/~striker/httpd-2.0.48-pre3/
> I haven't been pushing this release hard enough. It's dragging
> on way too long... Sorry about that.
I guess I didn't really make a difference last week...
Sander
RE: Tagged 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Jeff Trawick [mailto:trawick@attglobal.net]
> Sent: Wednesday, September 17, 2003 2:15 PM
> Sander Striker wrote:
>
> > I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've
> > put some tarballs containing that tag up at:
>
> There are some other fixes merged back since then, and it looks like
> another set of fixes that are close to being approved.
>
> Here is one issue I'd strongly suggest resolving for 2.0.48:
>
> Greg indicated in the last couple of days that www.apache.org had almost
> 12000 error messages (at that point) related to mutex errors with
> mod_rewrite. That affects flock users (e.g., FreeBSD) starting the
> server as root. I would suggest picking up this change to resolve that:
*nod* That'd be a good one to include.
> Beyond this one, I'm afraid that I'm not very familiar with the
> real-world implications of not picking up the other available fixes.
Everything that was voted upon can go in IMO. I was kind of hoping that
we could get this release out this week, but I'm afraid that's not going
to happen, if we want pre3 to serve on minotaur for a few days.
> I'd like to think that within a couple of days we could get 7 or 8 more
> fixes merged back, at which point we'd be ready for another release
> anyway. But it wouldn't be prudent to count on that happening ;)
Tell you what, if I see those merges start trickling in, I'll hold the
pre3 tag til friday. We'll put the thing on minotaur directly, and
announce to stable-testers. I'm hoping we can get enough +1s around
tuesday/wednesday to push out the final release.
I haven't been pushing this release hard enough. It's dragging
on way too long... Sorry about that.
Sander
Re: Tagged 2.0
Posted by Jeff Trawick <tr...@attglobal.net>.
Sander Striker wrote:
> I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've
> put some tarballs containing that tag up at:
There are some other fixes merged back since then, and it looks like
another set of fixes that are close to being approved.
Here is one issue I'd strongly suggest resolving for 2.0.48:
Greg indicated in the last couple of days that www.apache.org had almost
12000 error messages (at that point) related to mutex errors with
mod_rewrite. That affects flock users (e.g., FreeBSD) starting the
server as root. I would suggest picking up this change to resolve that:
- * Unix: Handle permissions settings for flock-based mutexes in
- unixd_set_global|proc_mutex_perms(). Allow the functions to
- be called for any type of mutex. PR 20312
- modules/mappers/mod_rewrite.c 1.153
- modules/ssl/mod_ssl.h 1.136
- modules/ssl/ssl_engine_config.c 1.81
- modules/ssl/ssl_engine_mutex.c 1.26
- os/unix/unixd.c 1.58
- os/unix/unixd.h 1.38
- +1: trawick, jerenkrantz, gregames
- 0: jim (it seems to me that the locking mech itself
- should have the required flags to determine whether
- uid/gid and chown is required, rather than placing
- that knowledge in unixd.c (kind of what is done for
- the SSL stuff already with ChownMutexFile). Thus
- unixd would simply check those out and do what is
- required rather than having internal APR knowledge
- it shouldn't).
I think the critical issue with this one is that, while the lessor-used
lock in mod_rewrite had this problem all along, another fix in 2.0.47
started doing the child-init on the other mod_rewrite lock and it too
picked up the root/flock issue.
Beyond this one, I'm afraid that I'm not very familiar with the
real-world implications of not picking up the other available fixes.
I'd like to think that within a couple of days we could get 7 or 8 more
fixes merged back, at which point we'd be ready for another release
anyway. But it wouldn't be prudent to count on that happening ;)
Re: Tagged 2.0
Posted by Bojan Smojver <bo...@rexursive.com>.
No worries. It's no hurry, just wanted to find out if it's still on the
radar. I have a workaround for the problem at hand (i.e. I'm inserting
flush buckets), so that's cool.
Once I'm out of the main work on my module, I might even take a look
myself. I don't think it'll be before Xmas, though :-(
On Thu, 2003-09-11 at 07:27, Cliff Woolley wrote:
> On Thu, 11 Sep 2003, Bojan Smojver wrote:
>
> > Just wanted to ask if there was any progress on the core_output_filter
> > in relation to multiple file buckets being passed through it?
>
> Not yet. I keep running out of time to look at it. Sorry for the delay...
> will get to it as soon as I can. Just wanted to let you know it hasn't
> completely fallen through the cracks. If anybody else wants to take a
> stab, feel free. Bojan posted a little sample module that demonstrates
> the problem a while back. It should be in the archive.
>
> --Cliff
--
Bojan
Re: Tagged 2.0
Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 11 Sep 2003, Bojan Smojver wrote:
> Just wanted to ask if there was any progress on the core_output_filter
> in relation to multiple file buckets being passed through it?
Not yet. I keep running out of time to look at it. Sorry for the delay...
will get to it as soon as I can. Just wanted to let you know it hasn't
completely fallen through the cracks. If anybody else wants to take a
stab, feel free. Bojan posted a little sample module that demonstrates
the problem a while back. It should be in the archive.
--Cliff
Re: Tagged 2.0
Posted by Bojan Smojver <bo...@rexursive.com>.
Just wanted to ask if there was any progress on the core_output_filter
in relation to multiple file buckets being passed through it?
On Wed, 2003-09-10 at 21:12, Sander Striker wrote:
> Hi,
>
> I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've
> put some tarballs containing that tag up at:
>
> http://www.apache.org/~striker/httpd-2.0.48-pre2/
>
> Testers, please test this release candidate.
>
> Thanks!
>
>
> Sander
>
> NB: I'll lay the final tag once the release candidate proves
> to be ok. This also includes bumping the version numbers
> to their final state (read: minus -dev).
--
Bojan
Re: Tagged 2.0
Posted by André Malo <nd...@perlig.de>.
* Sander Striker wrote:
> I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2.
Compiles fine on Win32 and my linux box (with prefork). A test suite run on the
latter gives the known mod_include failures plus the ssl/http.t failure,
because plain http on ssl port gives a HTTP/0.9 response. We should consider to
change that test ... :)
So +1 from me.
nd
Re: Tagged 2.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, September 10, 2003 5:58 PM -0700 Sander Temme
<sc...@covalent.net> wrote:
> configure:24363: checking whether getnameinfo resolves IPv4-mapped IPv6
> addresses
> configure:24426: gcc -o conftest -DDEBUG -O0 -DDYNAMIC_MODULE_LIMIT=128 -g
> -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
> -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp conftest.c >&5
> configure:24393: warning: return type of `main' is not `int'
> configure: In function `main':
> configure:24400: warning: implicit declaration of function `inet_addr'
> configure:24417: warning: implicit declaration of function `exit'
> configure:24429: $? = 0
> configure:24431: ./conftest
> configure:24434: $? = 0
> configure:24450: result: yes
> configure:24476: checking if APR supports IPv6
> configure:24478: result: yes
>
> This may be doing what it does for the wrong reasons.
Just to point out that those warnings in APR_CHECK_GETNAMEINFO_IPV4_MAPPED
derive from exactly the same snippet in APR_CHECK_GETNAMEINFO. So, any
warnings here are red herrings (or that check has exactly the same warnings).
Regardless, the macro was passing NI_NUMERICHOST instead of NI_NAMEREQD which
is what is needed to trigger the IPv4-IPv6 mapping oddity. I'll have to leave
it to someone else to backport to APR 0.9.x so it can be used in httpd 2.0.x.
-- justin
Re: Tagged 2.0
Posted by André Malo <nd...@perlig.de>.
Sander Temme wrote:
>The include failures are wholly new and generate two cores: from observing
>the run it looks like test 74 and 78 are crashing the server. Stack trace of
>the first crash (should be test 74:
>
>
No need to worry about this. The failures are old, just the tests
producing them are new. The rewrite of mod_include solves all these
problems (but wasn't applied yet to the 2.0 branch, since there there
are unresolved compat concerns).
nd
Re: Tagged 2.0
Posted by Sander Temme <sc...@covalent.net>.
> Testers, please test this release candidate.
Darwin 6.6 (MacOSX 10.2.6) gives me some new failures:
Failed Test Stat Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------------
modules/access.t 408 31 7.60% 4 20-21 24 26 28 30 38 55 72
89 106-107 123-124 141 154 168
170 175 192 209 226 277 290
304 306 311 328 345 362
modules/include.t 78 10 12.82% 9 18 34-35 40 42 74-75 77-78
ssl/http.t 255 65280 2 2 100.00% 1-2
The access failures look to me like a regression in the IPv6 issue: some
smarter logic was added to the apr build system to determine IPv6
brokenness, but I have seen this do strange things on my Powerbook... to
wit, consider the following snippet from srclib/apr/config.log:
configure:24363: checking whether getnameinfo resolves IPv4-mapped IPv6
addresses
configure:24426: gcc -o conftest -DDEBUG -O0 -DDYNAMIC_MODULE_LIMIT=128 -g
-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp conftest.c >&5
configure:24393: warning: return type of `main' is not `int'
configure: In function `main':
configure:24400: warning: implicit declaration of function `inet_addr'
configure:24417: warning: implicit declaration of function `exit'
configure:24429: $? = 0
configure:24431: ./conftest
configure:24434: $? = 0
configure:24450: result: yes
configure:24476: checking if APR supports IPv6
configure:24478: result: yes
This may be doing what it does for the wrong reasons.
The include failures are wholly new and generate two cores: from observing
the run it looks like test 74 and 78 are crashing the server. Stack trace of
the first crash (should be test 74:
Date/Time: 2003-09-10 17:42:09 -0700
OS Version: 10.2.6 (Build 6L60)
Host: MonaLisa
Command: httpd
PID: 4788
Exception: EXC_BAD_INSTRUCTION (0x0002)
Code[0]: 0x00000002Code[1]: 0x00789910
Thread 0 Crashed:
#0 0x00789910 in 0x789910
#1 0x003ed654 in send_parsed_content (mod_include.c:3153)
#2 0x003ee444 in includes_filter (mod_include.c:3426)
#3 0x0001b528 in ap_pass_brigade (util_filter.c:550)
#4 0x00442918 in bucketeer_out_filter (mod_bucketeer.c:133)
#5 0x0001b528 in ap_pass_brigade (util_filter.c:550)
#6 0x00017a3c in default_handler (core.c:3558)
#7 0x000301fc in ap_run_handler (config.c:195)
#8 0x00030ef8 in ap_invoke_handler (config.c:401)
#9 0x0000b0d4 in ap_process_request (http_request.c:288)
#10 0x00002cbc in ap_process_http_connection (http_core.c:295)
#11 0x00025ebc in ap_run_process_connection (connection.c:85)
#12 0x00026420 in ap_process_connection (connection.c:213)
#13 0x0000d2ac in child_main (prefork.c:695)
#14 0x0000d498 in make_child (prefork.c:791)
#15 0x0000d890 in perform_idle_server_maintenance (prefork.c:913)
#16 0x0000dea4 in ap_mpm_run (prefork.c:1118)
#17 0x0000fc20 in main (main.c:660)
#18 0x00002274 in _start (crt.c:267)
#19 0x000020f4 in start
PPC Thread State:
srr0: 0x00789910 srr1: 0x0208f030 vrsave: 0x00000000
xer: 0x00000000 lr: 0x0014c74c ctr: 0x00789910 mq: 0x00000000
r0: 0x00789910 r1: 0xbfffeee0 r2: 0x00789928 r3: 0x003928e4
r4: 0x0078b730 r5: 0x00000000 r6: 0x00000000 r7: 0x00000033
r8: 0x20646972 r9: 0x0078c5a4 r10: 0xbfffced6 r11: 0x00168328
r12: 0x00789910 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000
r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000
r24: 0x00000000 r25: 0x00000000 r26: 0xbffffc50 r27: 0x0000001c
r28: 0x00000006 r29: 0xbfffefb2 r30: 0xbfffeee0 r31: 0x003eca08
And the second crash (should be test 78):
Date/Time: 2003-09-10 17:42:23 -0700
OS Version: 10.2.6 (Build 6L60)
Host: MonaLisa
Command: httpd
PID: 4785
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000058
Thread 0 Crashed:
#0 0x00000058 in 0x58
#1 0x003ed264 in send_parsed_content (mod_include.c:3072)
#2 0x003ee444 in includes_filter (mod_include.c:3426)
#3 0x0001b528 in ap_pass_brigade (util_filter.c:550)
#4 0x00442ca8 in bucketeer_out_filter (mod_bucketeer.c:157)
#5 0x0001b528 in ap_pass_brigade (util_filter.c:550)
#6 0x00017a3c in default_handler (core.c:3558)
#7 0x000301fc in ap_run_handler (config.c:195)
#8 0x00030ef8 in ap_invoke_handler (config.c:401)
#9 0x0000b0d4 in ap_process_request (http_request.c:288)
#10 0x00002cbc in ap_process_http_connection (http_core.c:295)
#11 0x00025ebc in ap_run_process_connection (connection.c:85)
#12 0x00026420 in ap_process_connection (connection.c:213)
#13 0x0000d2ac in child_main (prefork.c:695)
#14 0x0000d498 in make_child (prefork.c:791)
#15 0x0000d574 in startup_children (prefork.c:806)
#16 0x0000dbe0 in ap_mpm_run (prefork.c:1023)
#17 0x0000fc20 in main (main.c:660)
#18 0x00002274 in _start (crt.c:267)
#19 0x000020f4 in start
PPC Thread State:
srr0: 0x00000058 srr1: 0x4200f030 vrsave: 0x00000000
xer: 0x00000000 lr: 0x003e6fd4 ctr: 0x00000058 mq: 0x00000000
r0: 0xbfffefc8 r1: 0xbfffef80 r2: 0x00000058 r3: 0x007a4bdc
r4: 0xbfffefc8 r5: 0xbfffefcc r6: 0x00000000 r7: 0x00000400
r8: 0x00000000 r9: 0xbfffefcc r10: 0x00000000 r11: 0x001682d4
r12: 0x00000058 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000
r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000
r24: 0x00000000 r25: 0x00000000 r26: 0xbffffc50 r27: 0x0000001c
r28: 0x00000006 r29: 0x007a4bd0 r30: 0xbfffef80 r31: 0x003eca08
Interestingly, running gdb on those cores produces entirely different
traces. These make much more sense. Maybe my gdb-fu is weak.
I think we should say something concise and sensible about the include
failures, and reinvestigate the IPv6 logic before releasing.
S. (my non-committer 2 cents worth)
--
Covalent Technologies sctemme@covalent.net
Engineering group Voice: (415) 856 4214
303 Second Street #375 South Fax: (415) 856 4210
San Francisco CA 94107
PGP FP: 7A8D B189 E871 80CB 9521 9320 C11E 7B47 964F 31D9
=======================================================
This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and
destroy all copies of the original message
=======================================================