Let's move this to dev@httpd and omit dev@apr (after this e-mail)...
On Sun, Nov 24, 2013 at 8:28 AM, olli hauer <oha...@gmx.de> wrote:
> On 2013-11-22 00:08, Jeff Trawick wrote:
> > On Thu, Nov 21, 2013 at 5:48 PM, olli hauer <oha...@gmx.de> wrote:
> >
> >> Hi,
> >>
> >> sorry for late response to apr-1.5.0 ...
> >>
> >> I've done some tests with apr-1.5.0 on FreeBSD 10 (amd64)
> >> and it seems there is an issue that breaks apache24.
> >>
> >> With apr-1.5.0 apache22 works but apache24 is broken.
> >> apache starts fine, nothing special in the logs or during
> >> start with -X but no response is coming back.
> >>
> >> apr/apr-util test:
> >> ========================================
> >> apr-1.5.0: all tests passed [1]
> >> apr-util-1.5.3: all tests passed
> >>
> >>
> >> working configurations (FreeBSD beta3 [1]
> >> =========================================
> >> apache22-2.2.26 apr-1.4.8 apr-util-1.5.3
> >> apache22-2.2.26 apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.6 apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.7 apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.6 apr-1.4.8 apr-util-1.5.3
> >> apache24-2.4.7 apr-1.4.8 apr-util-1.5.3
> >>
> >> broken combinations:
> >> =========================================
> >> apache24-2.4.6 apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.7 apr-1.5.0 apr-util-1.5.3
> >>
> >> All tests where done with MPM worker.
> >>
> >>
> >> FreeBSD 8.4 (amd64) seems OK in all combinations
> >> FreeBSD 9.2 (amd64) seems OK in all combinations
> >>
> >> [1] FreeBSD 10 beta3 with iconv UTF7 patch r258316
> >> (head/lib/libiconv_modules/UTF7/citrus_utf7.c)
> >>
> >> Any hints where to start?
> >>
> >
> > Set LogLevel trace8 and compare good vs. bad.
> > Start with -X then attach with dtruss and compare good vs. bad.
> > Get open fds displayed by lsof and compare good vs. bad.
> > Is connection to client held open? Get backtraces.
> >
> > I just compared 1.4.8 vs. 1.5.0 and didn't see anything that looked
> > remotely likely.
> >
>
> Comparing trace8 outputs showed the request is processed
> but the following code snippet in server/core_filters.c
> never get TRUE except the client cancels the request.
>
> To get some better log entries I've used server/core_filters.c
> r1510295 from trunk.
>
>
> @@server/core_filters.c (line 510)
> if (APR_BUCKET_IS_FLUSH(bucket)
> || non_file_bytes_in_brigade >= THRESHOLD_MAX_BUFFER
> || morphing_bucket_in_brigade
> || eor_buckets_in_brigade > MAX_REQUESTS_IN_PIPELINE) {
> ...
> }
>
> [http:trace3] http_filters.c(974):[client x.x.x.x:x] Response sent with
> status 200, headers:
> [http:trace5] http_filters.c(983):[client x.x.x.x:x] Date: Sun, 24 Nov
> 2013 10:28:37 GMT
> [http:trace5] http_filters.c(986):[client x.x.x.x:x] Server:
> Apache/2.4.7 (FreeBSD)
> [http:trace4] http_filters.c(804):[client x.x.x.x:x] Last-Modified: Sat,
> 23 Nov 2013 16:51:58 GMT
> [http:trace4] http_filters.c(804):[client x.x.x.x:x] ETag:
> \\"be-4ebdaf2ef2780\\"
> [http:trace4] http_filters.c(804):[client x.x.x.x:x] Accept-Ranges: bytes
> [http:trace4] http_filters.c(804):[client x.x.x.x:x] Content-Length: 190
> [http:trace4] http_filters.c(804):[client x.x.x.x:x] Keep-Alive:
> timeout=5, max=100
> [http:trace4] http_filters.c(804):[client x.x.x.x:x] Connection:
> Keep-Alive
> [http:trace4] http_filters.c(804):[client x.x.x.x:x] Content-Type:
> text/html
> [core:trace8] core_filters.c(576):[client x.x.x.x:x] brigade contains:
> bytes: 284, non-file bytes: 284, eor buckets: 0, morphing buckets: 0
> [core:trace8] core_filters.c(576):[client x.x.x.x:x] brigade contains:
> bytes: 474, non-file bytes: 284, eor buckets: 0, morphing buckets: 0
> [core:trace8] core_filters.c(576):[client x.x.x.x:x] brigade contains:
> bytes: 474, non-file bytes: 284, eor buckets: 1, morphing buckets: 0
>
>
> This following lines are only seen if
> apr-1-5.0 was build without IPv6 support
> or apache24 was build with v4-mapping enabled
> or "Listen $IP:$port" is given in httpd.conf
>
> [core:trace6] core_filters.c(526):[client x.x.x.x:x] will flush because of
> FLUSH bucket
> [core:trace8] core_filters.c(528):[client x.x.x.x:x] seen in brigade so
> far: bytes: 474, non-file bytes: 284, eor buckets: 1, morphing buckets: 0
> [core:trace8] core_filters.c(555):[client x.x.x.x:x] flushing now
> [core:trace8] core_filters.c(568):[client x.x.x.x:x] total bytes written:
> 474
> [core:trace8] core_filters.c(576):[client x.x.x.x:x] brigade contains:
> bytes: 0, non-file bytes: 0, eor buckets: 0, morphing buckets: 0
>
> However a flush is triggered if the client cancels the request, but no
> data is sent over the wire ...
>
>
> I've searched if other also have seen a similar issue and found
> instead the following interesting article from Nov. 2002 ;)
> http://people.apache.org/~trawick/v4mapped.html
>
>
I haven't analyzed the trace messages you showed above. Here's what I did
on FreeBSD 9:
Apply this patch to fix the version check for disabling v4mapped addresses:
Index: configure.in
===================================================================
--- configure.in (revision 1545127)
+++ configure.in (working copy)
@@ -774,7 +774,10 @@
],
[
case $host in
- *freebsd5*|*netbsd*|*openbsd*)
+ *freebsd[1234].*)
+ v4mapped=yes
+ ;;
+ *freebsd*|*netbsd*|*openbsd*)
v4mapped=no
;;
*)
That gives me
$ bin/apachectl -V
AH00558: httpd: Could not reliably determine the server's fully qualified
domain name, using 127.0.0.1. Set the 'ServerName' directive globally to
suppress this message
Server version: Apache/2.4.8-dev (Unix)
Server built: Nov 24 2013 20:21:30
Server's Module Magic Number: 20120211:27
Server loaded: APR 1.5.1-dev, APR-UTIL 1.5.4-dev
Compiled using: APR 1.5.1-dev, APR-UTIL 1.5.4-dev
Architecture: 64-bit
Server MPM: worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
The last line shown indicates that mapped addresses are disabled in this
build.
The only Listen I have is "Listen 8080". procstat says I have separate
sockets, as expected:
60734 httpd 3 s - rw---n--- 9 0 TCP ::.8080 ::.0
60734 httpd 4 s - rw---n--- 9 0 TCP 0.0.0.0:8080
0.0.0.0:0
>From netstat:
tcp4 0 0 *.8080 *.* LISTEN
tcp6 0 0 *.8080 *.* LISTEN
(You had shown sockstat before; this is the same stuff.)
--/--
Are you able to check for the issue on FreeBSD 9?
When it hangs, are you connecting to the IPv4 listener or the IPv6
listener? Does it matter whether you use loopback or the address of a
network interface?
You're using a regular web browser in the failing case, right? Have you
tried something as simple as netcat for the failing address/port? Example:
$ echo "GET /" | nc 127.0.0.1 8080
<html><body><h1>It works!</h1></body></html>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
