[Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0

[William A. Rowe, Jr.]

http://apr.apache.org/dev/dist/

+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0

Three packages so far to consider, votes welcome

[Brad Nicholes]

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ +1 ] apr-0.9.14
[ +1 ] apr-1.2.9
[ na ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

NetWare

Brad

[Bojan Smojver]

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

APR Compiles and passes tests when built as an RPM on Fedora 7, i386. On
x86_64, I get:
--------------------------------------
testlfs : Line 265: Large Files not supported
SUCCESS
--------------------------------------

Something isn't right here. I'm pretty sure Fedora 7 on x86_64 has large
file support and yet APR_HAS_LARGE_FILES gets set to zero.

[Bojan Smojver]

Post by Bojan Smojver
testlfs : Line 265: Large Files not supported

Or is this just a misleading message saying "these things are enabled by
default on this platform"?

[Davi Arnaut]

Post by Bojan Smojver

Post by Bojan Smojver
testlfs : Line 265: Large Files not supported

Or is this just a misleading message saying "these things are enabled by
default on this platform"?

Good question. LFS doesn't exist for 64 bit platforms, but because it
supports large files out of the box. This leads to another question,
should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems
reasonably safe to do so.

How about the following patch?

Index: configure.in
===================================================================
--- configure.in (revision 544571)
+++ configure.in (working copy)
@@ -454,7 +454,7 @@
struct stat64 st;
off64_t off = 4242;

- if (sizeof(off64_t) != 8 || sizeof(off_t) != 4)
+ if (sizeof(off64_t) != 8)
exit(1);
if ((fd = open("conftest.lfs", O_LARGEFILE|O_CREAT|O_WRONLY)) < 0)
exit(2);

[William A. Rowe, Jr.]

Post by Davi Arnaut

Post by Bojan Smojver

Post by Bojan Smojver
testlfs : Line 265: Large Files not supported

Or is this just a misleading message saying "these things are enabled by
default on this platform"?

Good question. LFS doesn't exist for 64 bit platforms, but because it
supports large files out of the box. This leads to another question,
should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems
reasonably safe to do so.

I've always understood HAS_LARGE_FILES to mean that offsets don't fit
into a size_t alignment, they are larger offsets than are otherwise
represented in memory. The thought that apr_off_t > off_t might also
fit that bill.

But no, we should probably figure out how to report this case more
intellegently in testlfs so people don't panic. LARGE_FILES, imho,
should not be set where special handling of the file offsets didn't
happen.

[Davi Arnaut]

Post by William A. Rowe, Jr.

Post by Davi Arnaut

Post by Bojan Smojver

Post by Bojan Smojver
testlfs : Line 265: Large Files not supported

Or is this just a misleading message saying "these things are enabled by
default on this platform"?

Good question. LFS doesn't exist for 64 bit platforms, but because it
supports large files out of the box. This leads to another question,
should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems
reasonably safe to do so.

I've always understood HAS_LARGE_FILES to mean that offsets don't fit
into a size_t alignment, they are larger offsets than are otherwise
represented in memory. The thought that apr_off_t > off_t might also
fit that bill.

As a user of the library, i would thought that with HAS_LARGE_FILES
apr_off_t is guaranteed to be 64 bits long. I wouldn't care about off_t,
since that's not portable.

Post by William A. Rowe, Jr.
But no, we should probably figure out how to report this case more
intellegently in testlfs so people don't panic. LARGE_FILES, imho,
should not be set where special handling of the file offsets didn't
happen.

I think that APR_HAS_LARGE_FILES should be defined whenever we have a 64
bits long apr_off_t, because that's probably what the user want to know
-- if the platform supports large files, which is true for 64 bit
systems. On 32-bits with LFS we should define an internal macro for
special handling of the file offsets. For example, testlfs.c is perfect
fine and should run on 64 bits platforms.

Although not a urgent issue, we should clarify and document better the
APR_HAS_LARGE_FILES meaning.

--
Davi Arnaut

[William A. Rowe, Jr.]

Post by Davi Arnaut

Post by William A. Rowe, Jr.
But no, we should probably figure out how to report this case more
intellegently in testlfs so people don't panic. LARGE_FILES, imho,
should not be set where special handling of the file offsets didn't
happen.

I think that APR_HAS_LARGE_FILES should be defined whenever we have a 64
bits long apr_off_t, because that's probably what the user want to know
-- if the platform supports large files, which is true for 64 bit
systems.

What is large? If on a future platform, if off_t (which -is- largely
portable, like ssize_t, just came a little after size_t) is 128 bits and
size_t is 64 bits, that's going to require exception code again.

You are reading APR_HAS_LARGE_FILES as APR_OFF_T_IS_64BIT, but this really
is not true. The flag LARGE_FILE to the apr_file_open tells the system
that you want to open the classic apr_file_t (in apr 0.9) in a mode where
it will handle offsets > size_t bytes wide.

LARGE_FILES tells us that a generic int/void* union will not hold the
offset into a file, and this isn't true of most 64 bit builds.

Post by Davi Arnaut
On 32-bits with LFS we should define an internal macro for
special handling of the file offsets.
For example, testlfs.c is perfect
fine and should run on 64 bits platforms.

This is trues

Post by Davi Arnaut
Although not a urgent issue, we should clarify and document better the
APR_HAS_LARGE_FILES meaning.

+1, after we figure out what that is:0

[Gringo Croco]

Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(

Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)

I've tested it twice, with a clean checkout of trunk both times; same behaviour.
All tests before this one worked fine.

--
Lucian Adrian Grijincu

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

[Lucian Adrian Grijincu]

I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)

I've done two tests. One in which I ran buildconf myself and one without.
For each test I then ran:
./configure
make
make test

Both failed with:
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog

the line possition it reports differs from run to run.

Same system: Ubuntu 7.04, 32bit.

Also:
Still haven't checked if this is to be expected running ./test/testall gives:
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)

Even though they pass when run from make check.

note trunk isn't 1.2.9 - it's actually 1.3.0 with some additional
socket features, so this is quite possibly not a problem with the
new tarball. would you mind also trying branches/1.2.x or the
tarball i created?

Post by Gringo Croco
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(
Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)
I've tested it twice, with a clean checkout of trunk both times; same
behaviour.
All tests before this one worked fine.
--
Lucian Adrian Grijincu

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

[Lucian Adrian Grijincu]

the cause: segmentation fault at:
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
the second parameter given is NULL:
apr_socket_bind (sock=0x80d3c78, sa=0x0) at network_io/unix/sockets.c:154

the NULL value comes from
rv = apr_sockaddr_info_get(&to, addr, APR_UNSPEC, 7772, 0, p);
Which was supposed to initialize it, but failed to.

digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
getaddrinfo's input params are:
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}

Will dig deeper, but if somebody has some knowledge why this would
fail, jump in :)

--
Lucian Adrian Grijincu

Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.

note trunk isn't 1.2.9 - it's actually 1.3.0 with some additional
socket features, so this is quite possibly not a problem with the
new tarball. would you mind also trying branches/1.2.x or the
tarball i created?

Post by Gringo Croco
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(
Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)
I've tested it twice, with a clean checkout of trunk both times; same
behaviour.
All tests before this one worked fine.
--
Lucian Adrian Grijincu

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

[Davi Arnaut]

Post by Lucian Adrian Grijincu
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
apr_socket_bind (sock=0x80d3c78, sa=0x0) at network_io/unix/sockets.c:154
the NULL value comes from
rv = apr_sockaddr_info_get(&to, addr, APR_UNSPEC, 7772, 0, p);
Which was supposed to initialize it, but failed to.
digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}

Hum, it seems the call_resolver (or the test) code is wrong because for
APR_UNSPEC it adds AI_ADDRCONFIG to the flags, which excludes loopback
addresses.

According to the getaddrinfo documentation, the loopback address is not
considered a valid configured address.

--
Davi Arnaut

[Colm MacCarthaigh]

Post by Davi Arnaut

Post by Lucian Adrian Grijincu
digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}

Hum, it seems the call_resolver (or the test) code is wrong because for
APR_UNSPEC it adds AI_ADDRCONFIG to the flags

Now looking at the actual bug in the test ...

Seems like it's acceptable to fall back to 127.0.0.1 in that situation
though, as an easy fix. So if we use the _info_get() call as the test
instead of "can we create an IPv6 socket", that's enough.

But if we do use IPv6, there are other problems, later on in the
code (at least on trunk) ...

164 apr_sockaddr_info_get(&from, "127.1.2.3", APR_INET, 4242, 0, p);
165
166 len = 80;
167 rv = apr_socket_recvfrom(from, sock, 0, recvbuf, &len);

if sock is an IPv6 socket, that's not going to be fun!

Looking at the test, I think we should have two tests, one for IPv6
and one for IPv4. Run them both, allow the IPv6 one to fail (if the
module is not loaded or whatever). Does that seem acceptable to
people ? I volunteer to help make the changes anyway, the current
state is a mess :-)

[William A. Rowe, Jr.]

Post by Colm MacCarthaigh
Looking at the test, I think we should have two tests, one for IPv6
and one for IPv4. Run them both, allow the IPv6 one to fail (if the
module is not loaded or whatever). Does that seem acceptable to
people ? I volunteer to help make the changes anyway, the current
state is a mess :-)

+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is? Or is there a simpler short term solution to let us get
together a solid 1.2.10 for httpd-2.2.5 and others who need a release
sooner rather than later?

Bill

[Colm MacCarthaigh]

Post by William A. Rowe, Jr.
+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is?

Nah, it's been like that for ages :-)

[Davi Arnaut]

Post by Colm MacCarthaigh

Post by William A. Rowe, Jr.
+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is?

Nah, it's been like that for ages :-)

In any case, I like to have a working make test. The patch attached has been
tested on Ubuntu and Fedora.

--
Davi Arnaut

[Lucian Adrian Grijincu]

I've gotten it down to this:
int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);

getaddrinfo hates "::1" as a node parameter.
I've attached a tester for getaddrinfo (based on Ulrich Drepper's
http://people.redhat.com/drepper/userapi-ipv6.html )

$> netstat -a -t -p
tcp 0 0 *:www *:*
LISTEN -
tcp6 0 0 *:ssh *:*
LISTEN -

$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported

$> telnet ::1 ssh
Trying ::1...
Connected to ::1.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1



$>./test ::1 www
./test: getaddrinfo: Address family for hostname not supported

$>telnet ::1 www
Trying ::1...
telnet: Unable to connect to remote host: Connection refused

both
$>./test 127.0.0.1 www
and
$>./test 127.0.0.1 ssh

succeed (aka I can talk to the www or ssh daemons running on my system).

If anyone's got a clue, please say so ... I'm kind of in the mists now :)
If not, when I get the time, I'll look into telnet's implementation to
see what they do to accept "::1"


--
Lucian Adrian Grijincu

Post by Lucian Adrian Grijincu
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
apr_socket_bind (sock=0x80d3c78, sa=0x0) at network_io/unix/sockets.c:154
the NULL value comes from
rv = apr_sockaddr_info_get(&to, addr, APR_UNSPEC, 7772, 0, p);
Which was supposed to initialize it, but failed to.
digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}
Will dig deeper, but if somebody has some knowledge why this would
fail, jump in :)
--
Lucian Adrian Grijincu

Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.

note trunk isn't 1.2.9 - it's actually 1.3.0 with some additional
socket features, so this is quite possibly not a problem with the
new tarball. would you mind also trying branches/1.2.x or the
tarball i created?

Post by Gringo Croco
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(
Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)
I've tested it twice, with a clean checkout of trunk both times; same
behaviour.
All tests before this one worked fine.
--
Lucian Adrian Grijincu

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

[Davi Arnaut]

Post by Lucian Adrian Grijincu
int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
getaddrinfo hates "::1" as a node parameter.
I've attached a tester for getaddrinfo (based on Ulrich Drepper's
http://people.redhat.com/drepper/userapi-ipv6.html )

<snip>

Post by Lucian Adrian Grijincu
If anyone's got a clue, please say so ... I'm kind of in the mists now :)
If not, when I get the time, I'll look into telnet's implementation to
see what they do to accept "::1"

See my email about it, message id <***@haxent.com.br>

It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).

--
Davi Arnaut

[William A. Rowe, Jr.]

Post by Davi Arnaut
It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).

Thanks for the research, which solution do we want?

[ ] undo the AI_ADDRCONFIG flag which interferes with loopback?
[ ] document that loopback isn't a valid address?

I'm guessing the former.

Bill

[Colm MacCarthaigh]

Post by Davi Arnaut
It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).

O.k., I think you're mis-interpretting things here. The purpose of the
AI_ADDRCONFIG flag is to determine if getaddrinfo should bother to
return IPv6 addresses or not, it's a basic "Do I actually have IPv6
connectivity?" test.

It works by determining if your system has a useable non-localhost IPv6
address set, so if I have 2001:770:18::2 on an interface the answer is
"yes". "::1" is not treated at all differently by getaddrinfo as a
parameter. Where ::1 comes in is that if it's the only IPv6 address
configured on your system, the answer to the AI_ADDRCONFIG test is "no".
Having ::1 does not mean you have useable IPv6 connectivity generally,
and so the aim is that the call does not return it.

In other words, if I ran this test on my system, which does have
a public IPv6 address, it would work just fine. "::1" as a parameter
is not special.

Does that make sence? I can explain more verbosely too.

[Davi Arnaut]

Post by Colm MacCarthaigh

Post by Davi Arnaut
It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).

O.k., I think you're mis-interpretting things here. The purpose of the
AI_ADDRCONFIG flag is to determine if getaddrinfo should bother to
return IPv6 addresses or not, it's a basic "Do I actually have IPv6
connectivity?" test.

Yes, i'm pretty confused by AI_ADDRCONFIG.

Post by Colm MacCarthaigh
It works by determining if your system has a useable non-localhost IPv6
address set, so if I have 2001:770:18::2 on an interface the answer is
"yes". "::1" is not treated at all differently by getaddrinfo as a
parameter. Where ::1 comes in is that if it's the only IPv6 address
configured on your system, the answer to the AI_ADDRCONFIG test is "no".
Having ::1 does not mean you have useable IPv6 connectivity generally,
and so the aim is that the call does not return it.
In other words, if I ran this test on my system, which does have
a public IPv6 address, it would work just fine. "::1" as a parameter
is not special.
Does that make sence? I can explain more verbosely too.

Sorry, but i still don't quite understand. For example:

/Users/davi/gai $ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC,
.hints=0|AI_ADDRCONFIG|AI_NUMERICHOST}) = 0:
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0

How come this succeeded? The system doesn't have any public ipv6,
the only "configured" ipv6 address is ::1.

/Users/davi/gai $ ./gai -na
getaddrinfo(NULL, NULL, {.family=AF_UNSPEC,
.hints=0|AI_ADDRCONFIG|AI_NUMERICHOST}) = -1:
error: nodename nor servname provided, or not known

--
Davi Arnaut

[Colm MacCarthaigh]

Post by Davi Arnaut
/Users/davi/gai $ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC,
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
How come this succeeded? The system doesn't have any public ipv6,
the only "configured" ipv6 address is ::1.

AI_NUMERICHOST trumps AI_ADDRCONFIG on some platforms because people
infer that if you supply it you are being more specific in your request.
The technical reason is because the decision to make an AAAA query or
not is buried in their resolver code (*cough*, this may or may not be my
fault) , and that code never gets triggered when you use AI_NUMERICHOST.

It's not strictly in the letter of rfc3493 though, it's a resolver bug.

Post by Davi Arnaut
/Users/davi/gai $ ./gai -na
getaddrinfo(NULL, NULL, {.family=AF_UNSPEC,
error: nodename nor servname provided, or not known

Why wouldn't that fail?

[Davi Arnaut]

Post by Colm MacCarthaigh

Post by Davi Arnaut
/Users/davi/gai $ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC,
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
How come this succeeded? The system doesn't have any public ipv6,
the only "configured" ipv6 address is ::1.

AI_NUMERICHOST trumps AI_ADDRCONFIG on some platforms because people
infer that if you supply it you are being more specific in your request.
The technical reason is because the decision to make an AAAA query or
not is buried in their resolver code (*cough*, this may or may not be my
fault) , and that code never gets triggered when you use AI_NUMERICHOST.
It's not strictly in the letter of rfc3493 though, it's a resolver bug.

Ok, ack.

Post by Colm MacCarthaigh

Post by Davi Arnaut
/Users/davi/gai $ ./gai -na
getaddrinfo(NULL, NULL, {.family=AF_UNSPEC,
error: nodename nor servname provided, or not known

Why wouldn't that fail?

Sorry, it should have been:

getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = 0:
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0

Last question (sorry for wasting your time), why this one succeeded?

--
Davi Arnaut

[Colm MacCarthaigh]

Post by Davi Arnaut

Post by Colm MacCarthaigh
Why wouldn't that fail?

family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
Last question (sorry for wasting your time), why this one succeeded?

If you don't have a public IPv6 address, per the RFC - it should fail,
it's a resolver bug.

In the real world, it could be NSCD, or another libc cache :-)

[Joe Orton]

Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.

That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?

joe

[Davi Arnaut]

Post by Joe Orton

Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.

That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?

In case anyone wanna try.. test attached.

--
Davi Arnaut

[Lucian Adrian Grijincu]

Post by Davi Arnaut

Post by Joe Orton

Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.

That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?

***@h:~$ lsmod | grep ipv6
ipv6 268960 12

I guess 2.5 :)
Ubuntu reports it as 2.5-0ubuntu14

***@h:~$ ls -al /lib/libc.so.6
lrwxrwxrwx 1 root root 11 2007-05-18 01:12 /lib/libc.so.6 -> libc-2.5.so

I think that telnet could see that "::1" is the IPv6 loopback string
and replace it with "127.0.0.1" if it wanted. Haven' looked at the
code, just why this behaviour may be possible.

Post by Davi Arnaut
In case anyone wanna try.. test attached.

This is the output:
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

--
Lucian Adrian Grijincu

[Joe Orton]

Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

Just so I can understand the precise nuances of this, can you post the
output of:

wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6

But yes, testsockets.c will need some tweaking to cope with this
getaddrinfo implementation. I think it's caused by an Ubuntu patch, if
I read https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
correctly. It might break some applications in fun ways too, but
there's not much APR can do about that.

joe

[Davi Arnaut]

Post by Joe Orton

Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6

Ubuntu 7.04 (no ipv6 addresses -- other then loopback -- configured):

***@karmic:~/gai$ make gai
cc gai.c -o gai
***@karmic:~/gai$ ./gai ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0}) = 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0}) = 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai -a ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = -1:
error: Address family for hostname not supported
***@karmic:~/gai$ ./gai -a ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG}) = -1:
error: Name or service not known

Post by Joe Orton
But yes, testsockets.c will need some tweaking to cope with this
getaddrinfo implementation. I think it's caused by an Ubuntu patch, if
I read https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
correctly. It might break some applications in fun ways too, but
there's not much APR can do about that.

Interesting bits of documentation:

win32:

"If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system, and
IPv6 addresses shall be returned only if an IPv6 address is configured
on the local system. The IPv4 or IPv6 loopback address is not considered
a valid global address."

RFC 3943:

"If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system,
and IPv6 addresses shall be returned only if an IPv6 address is
configured on the local system. The loopback address is not
considered for this case as valid as a configured address."

Solaris:

"If the AI_ADDRCONFIG flag is specified, IPv4 addresses are returned
only if an IPv4 address is configured on the local system, and IPv6
addresses are returned only if an IPv6 address is configured on the
local system. For this case, the loopback address is not considered to
be as valid as a configured address. "

--
Davi Aranut

[Davi Arnaut]

Post by Joe Orton

Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6

Solaris:

[***@sunfire280 x]$ ./gai ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0}) = 0:
family=26, proto= 0 inet6: addr=::1, port=0, flowinfo=0

[***@sunfire280 x]$ ./gai ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0}) = 0:
family=26, proto= 0 inet6: addr=::1, port=0, flowinfo=0

[***@sunfire280 x]$ ./gai -a ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = 0:
family=26, proto= 0 inet6: addr=::1, port=0, flowinfo=0

[***@sunfire280 x]$ ./gai -a ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG}) = 0:

[Davi Arnaut]

Post by Davi Arnaut

Post by Joe Orton

Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6

cc gai.c -o gai
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|
error: Address family for hostname not supported
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|
error: Name or service not known

Same machine, now with -n:

***@karmic:~/gai$ ./gai -n ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|
AI_NUMERICHOST}) = 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai -n ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_NUMERICHOST})
= 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG|
AI_NUMERICHOST}) = -1:
error: Address family for hostname not supported
***@karmic:~/gai$ ./gai -na ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG|
AI_NUMERICHOST}) = -1:
error: Name or service not known

[Joe Orton]

Thanks. Was the last line omitted from the results for Solaris which
you posted, or was it really a NULL result list?

I don't think this provides any reason to change the APR resolver code.
Ubuntu systems may be a bit schizophrenic about whether ::1 exists,
depending on whether your app uses AI_ADDRCONFIG or not, but it seems to
be by design.

The testsockets.c problem is certainly not new, I don't see why it
should block a release. That code has always been pretty fragile.

joe

[Davi Arnaut]

Post by Joe Orton
Thanks. Was the last line omitted from the results for Solaris which
you posted, or was it really a NULL result list?

Probably omitted -- cut-and-pasted from chat log.

Post by Joe Orton
I don't think this provides any reason to change the APR resolver code.
Ubuntu systems may be a bit schizophrenic about whether ::1 exists,
depending on whether your app uses AI_ADDRCONFIG or not, but it seems to
be by design.
The testsockets.c problem is certainly not new, I don't see why it
should block a release. That code has always been pretty fragile.

+1

[Lucian Adrian Grijincu]

Post by Joe Orton
Thanks. Was the last line omitted from the results for Solaris which
you posted, or was it really a NULL result list?
I don't think this provides any reason to change the APR resolver code.
Ubuntu systems may be a bit schizophrenic about whether ::1 exists,
depending on whether your app uses AI_ADDRCONFIG or not, but it seems to
be by design.

The code that sets AI_ADDRCONFIG checks the error message returned by
getaddrinfo. If family was APR_UNSPEC and the error was EAI_BADFLAGS
(which basically means failed because of a bad flag:) ) it retries
with flags set to null.

I think the Ubuntu 7.04 people wrongfully return EAI_ADDRFAMILY, when
EAI_BADFLAGS would be just fine, because changing the flag makes the
call succeed and there is a ::1 address in the specified family.

A solution that *works* is to check for both error codes and if either
is returned and were in APR_UNSPEC mode, retry without EAI_ADDRFAMILY.

Post by Joe Orton
The testsockets.c problem is certainly not new, I don't see why it
should block a release. That code has always been pretty fragile.
joe

--
Lucian Adrian Grijincu

[Colm MacCarthaigh]

Post by Joe Orton

Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c

This won't help this time :/ The key thing is that AI_ADDRCONFIG
makes getaddrinfo behave differently based on what addresses are
configured on your systems interfaces, not based on any other
parameters to getaddrinfo.

[Tollef Fog Heen]

* Joe Orton

| But yes, testsockets.c will need some tweaking to cope with this
| getaddrinfo implementation. I think it's caused by an Ubuntu patch, if
| I read https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
| correctly. It might break some applications in fun ways too, but
| there's not much APR can do about that.

FWIW, I have yet to see any bug reports about anything breaking with
this, except testsockets.c.

What the glibc patch does is it only returns IPv6 addresses if they
are explicitly requested by the application or you have an IPv6
address with a scope of < link (that is, if you have site or global
scope address).

The reason for the patch is lots of cheap DSL routers seem to just not
respond to AAAA or A6 queries, so applications would try to resolve a
name, glibc would send out an AAAA query, wait for it to time out,
then send out an A request instead of just getting a NXDOMAIN or
similar back immediately. So, it's a hack for brokenness in lots of
software which is not Ubuntu's, but it makes the user experience much
better without breaking IPv6 for those who actually use it.

Whether it should treat numeric addresses specifically is something I
had not considered; maybe it should. I would be happy to receive
feedback on this. On the other hand, I would suspect the number of
people keying in IPv6 addresses into their applications and not having
a site or global IPv6 address to be fairly small so real-world
breakage should be limited.

[Lucian Adrian Grijincu]

Post by Lucian Adrian Grijincu

Post by Davi Arnaut

Post by Joe Orton

Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.

That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?

ipv6 268960 12
I guess 2.5 :)
Ubuntu reports it as 2.5-0ubuntu14
lrwxrwxrwx 1 root root 11 2007-05-18 01:12 /lib/libc.so.6 -> libc-2.5.so
I think that telnet could see that "::1" is the IPv6 loopback string
and replace it with "127.0.0.1" if it wanted. Haven' looked at the
code, just why this behaviour may be possible.

Post by Davi Arnaut
In case anyone wanna try.. test attached.

getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

commenting out AI_ADDRCONFIG in the malfunctioning code makes it pass all tests.

#ifdef HAVE_GAI_ADDRCONFIG
if (family == APR_UNSPEC) {
/* By default, only look up addresses using address types for
* which a local interface is configured, i.e. no IPv6 if no
* IPv6 interfaces configured. */

//hints.ai_flags = AI_ADDRCONFIG;
}
#endif

I hear that there are real performance reasons to maintain
AI_ADDRCONFIG for AF_UNSPEC:
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html

I first though we could do a strcmp to check for "127.0.0.1" or "::1",
but it's not going to work, because users may have altered the hosts
file to set a specific hostname to loopback and this code should be
able to get things like "localhost" as a valid parameter.

I see three getaways:
1. kill AI_ADDRCONFIG for APR_UNSPEC
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
3. retry without AI_ADDRCONFIG if first try fails

1. BAD: this is the only place where AI_ADDRCONFIG is used and not
using it would mean a performance regression for applications that do
not care about loopback.
2. UGLY: APR should work arround platform specific issues and present
a simple interface. Having the user check for link-localness
beforehand is ... ugly. :)
3. GOOD: We already retry for some other errors and retrying would
only harm performance-wise only in case of a:
a) link-local address or hostname. This should be resolved locally,
which means the drawback is little
b) failing external lookup. This can mean we'll take longer to say:
"I can't find the hostname you specified", or (not very probable)
manage to find it at the second try


I've attached a patch against the tarball that does what's needed for 3.

Rebuilt from scratch + patch:
finally, all test pass now :)


--
Lucian Adrian Grijincu

[William A. Rowe, Jr.]

Post by Lucian Adrian Grijincu
I hear that there are real performance reasons to maintain
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html
I first though we could do a strcmp to check for "127.0.0.1" or "::1",
but it's not going to work, because users may have altered the hosts
file to set a specific hostname to loopback and this code should be
able to get things like "localhost" as a valid parameter.

Correct, that won't work. Although looking for "127." or "::" prefixes
might be a legimate test, however "localhost" won't resolve.

Remember that setting up the loopback IP's .1, .2, .3, .4 all on the
same port might be a reasonable design of a local app and wouldn't pass
if you looked for the full loopback IP.

Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
3. retry without AI_ADDRCONFIG if first try fails
1. BAD: this is the only place where AI_ADDRCONFIG is used and not
using it would mean a performance regression for applications that do
not care about loopback.
2. UGLY: APR should work arround platform specific issues and present
a simple interface. Having the user check for link-localness
beforehand is ... ugly. :)
3. GOOD: We already retry for some other errors and retrying would
a) link-local address or hostname. This should be resolved locally,
which means the drawback is little
"I can't find the hostname you specified", or (not very probable)
manage to find it at the second try
I've attached a patch against the tarball that does what's needed for 3.
finally, all test pass now :)

I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)

Bill

[Ruediger Pluem]

Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)

I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?

Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.

Regards

Rüdiger

[William A. Rowe, Jr.]

Post by Ruediger Pluem

Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)

I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?
Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.

IIUC - this patch does NOT add -L/path at all for /usr/lib, /usr/lib64, if the
compiler resolves the -lexpat, correct?

If so, amen! Be my guest to get this committed and get our fingers our of the
compiler's business.

[Ruediger Pluem]

Post by William A. Rowe, Jr.

Post by Ruediger Pluem

Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)

I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?
Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.

IIUC - this patch does NOT add -L/path at all for /usr/lib, /usr/lib64, if the
compiler resolves the -lexpat, correct?

Looks like to me. Maybe Joe can confirm.

Regards

Rüdiger

[Joe Orton]

Post by Ruediger Pluem

Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)

I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?
Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.

I was hoping to see this get some testing on some more exotic/less
modern systems, to try to flush out any regressions :(

But since more and more systems are hitting this it's probably worth
including in 1.2.x. Thanks for the backport, testing, and persistence -
r545129.

joe

[William A. Rowe, Jr.]

Post by Joe Orton
I was hoping to see this get some testing on some more exotic/less
modern systems, to try to flush out any regressions :(

Well the new logic is quite clean. Someday a lcllibpth like variable
that perl builds would be sweet (for searching the unusual/platform
specific locations like /sw/bin, /opt/sfw, /usr/sfw etc). Nothing
wrong with asking users to be specific if it's not in the expected
locations, though.

Post by Joe Orton
But since more and more systems are hitting this it's probably worth
including in 1.2.x. Thanks for the backport, testing, and persistence -
r545129.

Not that we care quite so much anymore, but does 0.9 hit the same issue?

[William A. Rowe, Jr.]

can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?
http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser
It's an implementation of "rm -d -r" based only on APR objects.

Of course, it's too late to extend the 1.2 api, this could be backported
to 0.9 if you desired, and added to trunk of course.

1. drop the file in unix/
2. add a new #SOURCE section in the libapr.dsp and apr.dsp win32 build
files which add that new source (pointing to the unix tree).
3. for other platforms which -exist- (don't add a platform, the build will
default to unix/ where another doesn't exist) add the same-named source
consisting of nothing but an #include "../unix/foo.c" which means we have
only one source to maintain.
4. add to the NW build (ENOCLUE offhand, you might look at a recent commit
or someone else might pipe in).

[Davi Arnaut]

can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?
http://mail-archives.apache.org/mod_mbox/apr-dev/200705.mbox/%
http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser
It's an implementation of "rm -d -r" based only on APR objects.

Clueless question: Would it be better to use ftw() (or nftw(), or fts
()) for traversing?

--
Davi Arnaut

[Brad Nicholes]

Post by Lucian Adrian Grijincu

can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?

http://mail-archives.apache.org/mod_mbox/apr-dev/200705.mbox/%3c4d45da0507051

http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser
It's an implementation of "rm -d -r" based only on APR objects.

Of course, it's too late to extend the 1.2 api, this could be backported
to 0.9 if you desired, and added to trunk of course.
1. drop the file in unix/
2. add a new #SOURCE section in the libapr.dsp and apr.dsp win32 build
files which add that new source (pointing to the unix tree).
3. for other platforms which -exist- (don't add a platform, the build will
default to unix/ where another doesn't exist) add the same-named source
consisting of nothing but an #include "../unix/foo.c" which means we have
only one source to maintain.
4. add to the NW build (ENOCLUE offhand, you might look at a recent commit
or someone else might pipe in).

In most cases for NetWare, just add the file to the appropriate unix dir and then add the file name to the corresponding NWGnuMakefile.

[Lucian Adrian Grijincu]

Post by William A. Rowe, Jr.

Post by Lucian Adrian Grijincu
I hear that there are real performance reasons to maintain
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html
I first though we could do a strcmp to check for "127.0.0.1" or "::1",
but it's not going to work, because users may have altered the hosts
file to set a specific hostname to loopback and this code should be
able to get things like "localhost" as a valid parameter.

Correct, that won't work. Although looking for "127." or "::" prefixes
might be a legimate test, however "localhost" won't resolve.
Remember that setting up the loopback IP's .1, .2, .3, .4 all on the
same port might be a reasonable design of a local app and wouldn't pass
if you looked for the full loopback IP.

Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
3. retry without AI_ADDRCONFIG if first try fails
1. BAD: this is the only place where AI_ADDRCONFIG is used and not
using it would mean a performance regression for applications that do
not care about loopback.
2. UGLY: APR should work arround platform specific issues and present
a simple interface. Having the user check for link-localness
beforehand is ... ugly. :)
3. GOOD: We already retry for some other errors and retrying would
a) link-local address or hostname. This should be resolved locally,
which means the drawback is little
"I can't find the hostname you specified", or (not very probable)
manage to find it at the second try
I've attached a patch against the tarball that does what's needed for 3.
finally, all test pass now :)

I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)

Hi Bill,

Please look at the immensity of the patch I submitted:

339c339
< if ((error == EAI_BADFLAGS || error == EAI_ADDRFAMILY ) &&
family == APR_UNSPEC) {
---

Post by William A. Rowe, Jr.
if (error == EAI_BADFLAGS && family == APR_UNSPEC) {

which comes in this context:
error = getaddrinfo(hostname, servname, &hints, &ai_list);
#ifdef HAVE_GAI_ADDRCONFIG
if ((error == EAI_BADFLAGS || error == EAI_ADDRFAMILY ) && family
== APR_UNSPEC) {
/* Retry with no flags if AI_ADDRCONFIG was rejected. */
hints.ai_flags = 0;
error = getaddrinfo(hostname, servname, &hints, &ai_list);
}
#endif

I agree that this thing needs to be rechecked on all platforms, it's
just the sane thing to do, but I'd suggest that the 1.2.10 contain
this check and not dump the AI_ADDRCONFIG flag altogether.


Disclaimer: I haven't worked with autoconf automake etc. and I really
don't have the time :(

can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?

I'd like to see this:
http://mail-archives.apache.org/mod_mbox/apr-dev/200705.mbox/%***@mail.gmail.com%3e
included in APR. It's been discussed in december 2006 too:
http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser

It's an implementation of "rm -d -r" based only on APR objects.

--
Thank you,
Lucian Adrian Grijincu

[Colm MacCarthaigh]

Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC

In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.

Post by Lucian Adrian Grijincu
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.

This is not true, see my other mail.

Post by Lucian Adrian Grijincu
3. retry without AI_ADDRCONFIG if first try fails

This sucks. I prefer this:

4. Add APR_NUMERIC_ADDRESS, and set the AI_NUMERICHOST hint, when
passed *don't* set AI_ADDRCONFIG. Document that people who
want to perform a literal IP translation - regardless of
connectivity - should use it.

E.g., if I want to turn "::1" into a structure I can use
and I totally don't care if I have general IPv6 connectivity
or if I even have connectivity to ::1 itself, I should use this
flag.

[Colm MacCarthaigh]

<snip from=man getaddrinfo(3)>
If hints.ai_flags contains the
AI_NUMERICHOST flag then the node parameter must be a numerical
network
address. The AI_NUMERICHOST flag suppresses any potentially
lengthy
network host address lookups.
</snip>
how does this work with string names like "localhost" too?

Eh, it doesn't, that's why it's got the word numeric in there ;-) But if
people want to translate literal IP addresses into addrinfo structures
regardless of connectivity - that's how to do it.

As I understand the APR interface that's misbehaving now needs to
support hostnames besides IPs represented as strings.

Very much so, that's the majority use-case by a long long way, it works
fine btw!

Suppose that a this string is read from the commandline as a
parameter. The app coder cannot pass this new APR_NUMERIC_ADDRESS
flag, because he doesn't know if the string he received is a name for
a link-local IP.

Firstly: I'm not sure what your point here is :-) That wouldn't be the
use-case.

Secondly: It's incredibly trivial to tell if a string is a literal IP
address or not, they are programatically distinguishable from hostnames
with extreme ease. But it'd be a bad idea to do that, still not the
use-case!

[Colm MacCarthaigh]

You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
"::1" in a call to apr_sockaddr_info_get, they should pass in this
flag as well, to be sure that the call succeeds on Ubuntu 7.04 32bit
too.

If we want to support this behaviour at all, we should. In general
though I'd have thought apr_inet_pton is sufficient, and that apr as a
whole does not need it. But for some reason folk seem to want
getaddrinfo("::1", ...) to magically work in spite of the what the RFCs
say , I'm just giving options here :-)

What would that programmer do if it had to pass a hostname to
apr_sockaddr_info_get and that name would point to "::1".

Just not set the flag, since it's not a numeric address.

I added this to my /etc/hosts "::1 my_name_lo"
and modified the testsocket.c file that failed replacing "::1" with
"my_name_lo".
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828 some
explanation for this behaviour on this platform.)

But the test should fail in that scenario, I don't see a problem.

What good would APR_NUMERIC_ADDRESS do in this case?

Like I said, that is not the use-case.

[Colm MacCarthaigh]

a) either have different behaviour on different platforms (Ubuntu 7.4
(and everything based on it) vs. the rest).

AI_ADDRCONFIG behaviour is not supported on plenty of platforms yet,
yes, but it's backwards compatible, it's a safe default too, I
don't see how the difference in behaviour affects users of the API.
As long as you do:

linked-list-result = apr_sockaddr_info_get ("opaque-string")

foreach node in linked-list-result do:
listen() or connect()

there is no problem. The problem *only* arises if you use
apr_sockaddr_info_get("::1") and some kind of niaive "do I have working
IPv6" test. But it's a resolver, nothing else, that usage falls outside
of common or reasonable behaviour IMO.

On platforms that support the AI_ADDRCONFIG behaviour our users get to
avoid an unneccessary listen() or connect() call (and corresponding
delay and timeout). This is a big win!

b) or document that this function must not be used with strings
representing link-local IPv6 IPs or hostnames to link-local IPv6 IPs.

link-local addresses are something else again, but you can getaddrinfo()
a link-local address just fine, if you really want to. Don't expect it
to be very useful in a L3 application though!

Did I understand right?

No :-)

Post by Colm MacCarthaigh

What good would APR_NUMERIC_ADDRESS do in this case?

Like I said, that is not the use-case.

I first understood that you were referring to the use-case of
"hostnames to IPv6 link-local IPs" in relation to
apr_sockaddr_info_get, not APR_NUMERIC_ADDRESS. Sorry it's kindof
early in the morning on my side of the planet and I'm subject to
self-imposed sleep-deprivation.

I've never mentioned link-local IPs! The use-case I was responding about
is the one in the test, namely wanting "::1" to always resolve, no
matter what. That's a very special case (for which apr_inet_pton or an
entirely different approach are better suited).

[Lucian Adrian Grijincu]

Post by Colm MacCarthaigh

You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
"::1" in a call to apr_sockaddr_info_get, they should pass in this
flag as well, to be sure that the call succeeds on Ubuntu 7.04 32bit
too.

If we want to support this behaviour at all, we should. In general
though I'd have thought apr_inet_pton is sufficient, and that apr as a
whole does not need it. But for some reason folk seem to want
getaddrinfo("::1", ...) to magically work in spite of the what the RFCs
say , I'm just giving options here :-)

What would that programmer do if it had to pass a hostname to
apr_sockaddr_info_get and that name would point to "::1".

Just not set the flag, since it's not a numeric address.

I added this to my /etc/hosts "::1 my_name_lo"
and modified the testsocket.c file that failed replacing "::1" with
"my_name_lo".
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828 some
explanation for this behaviour on this platform.)

From this: " > But the test should fail in that scenario, I don't see
a problem." I understand that we:

a) either have different behaviour on different platforms (Ubuntu 7.4
(and everything based on it) vs. the rest).
b) or document that this function must not be used with strings
representing link-local IPv6 IPs or hostnames to link-local IPv6 IPs.

Did I understand right?

Post by Colm MacCarthaigh

What good would APR_NUMERIC_ADDRESS do in this case?

Like I said, that is not the use-case.

I first understood that you were referring to the use-case of
"hostnames to IPv6 link-local IPs" in relation to
apr_sockaddr_info_get, not APR_NUMERIC_ADDRESS. Sorry it's kindof
early in the morning on my side of the planet and I'm subject to
self-imposed sleep-deprivation.

Post by Colm MacCarthaigh
--

[Lucian Adrian Grijincu]

Post by Colm MacCarthaigh

<snip from=man getaddrinfo(3)>
If hints.ai_flags contains the
AI_NUMERICHOST flag then the node parameter must be a numerical network
address. The AI_NUMERICHOST flag suppresses any potentially
lengthy
network host address lookups.
</snip>
how does this work with string names like "localhost" too?

Eh, it doesn't, that's why it's got the word numeric in there ;-) But if
people want to translate literal IP addresses into addrinfo structures
regardless of connectivity - that's how to do it.

As I understand the APR interface that's misbehaving now needs to
support hostnames besides IPs represented as strings.

Very much so, that's the majority use-case by a long long way, it works
fine btw!

Suppose that a this string is read from the commandline as a
parameter. The app coder cannot pass this new APR_NUMERIC_ADDRESS
flag, because he doesn't know if the string he received is a name for
a link-local IP.

Firstly: I'm not sure what your point here is :-) That wouldn't be the
use-case.

You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
"::1" in a call to apr_sockaddr_info_get, they should pass in this
flag as well, to be sure that the call succeeds on Ubuntu 7.04 32bit
too.

What would that programmer do if it had to pass a hostname to
apr_sockaddr_info_get and that name would point to "::1".

More verbose:
I added this to my /etc/hosts "::1 my_name_lo"
and modified the testsocket.c file that failed replacing "::1" with
"my_name_lo".
The test failed (on Ubuntu 7.04, see here:
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828 some
explanation for this behaviour on this platform.)

What good would APR_NUMERIC_ADDRESS do in this case?

Or maybe I haven't understood what you were proposing ...

--
Lucian Adrian Grijincu

Post by Colm MacCarthaigh
Secondly: It's incredibly trivial to tell if a string is a literal IP
address or not, they are programatically distinguishable from hostnames
with extreme ease. But it'd be a bad idea to do that, still not the
use-case!
--

[Lucian Adrian Grijincu]

Post by Colm MacCarthaigh

Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC

In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.

Post by Lucian Adrian Grijincu
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.

This is not true, see my other mail.

Post by Lucian Adrian Grijincu
3. retry without AI_ADDRCONFIG if first try fails

4. Add APR_NUMERIC_ADDRESS, and set the AI_NUMERICHOST hint, when
passed *don't* set AI_ADDRCONFIG. Document that people who
want to perform a literal IP translation - regardless of
connectivity - should use it.
E.g., if I want to turn "::1" into a structure I can use
and I totally don't care if I have general IPv6 connectivity
or if I even have connectivity to ::1 itself, I should use this
flag.
--

<snip from=man getaddrinfo(3)>
If hints.ai_flags contains the
AI_NUMERICHOST flag then the node parameter must be a numerical network
address. The AI_NUMERICHOST flag suppresses any potentially lengthy
network host address lookups.
</snip>

how does this work with string names like "localhost" too?
As I understand the APR interface that's misbehaving now needs to
support hostnames besides IPs represented as strings.

Suppose that a this string is read from the commandline as a
parameter. The app coder cannot pass this new APR_NUMERIC_ADDRESS
flag, because he doesn't know if the string he received is a name for
a link-local IP.

[Jeff Trawick]

Post by Colm MacCarthaigh

Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC

In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.

+1

Post by Colm MacCarthaigh
4. Add APR_NUMERIC_ADDRESS, and set the AI_NUMERICHOST hint, when
passed *don't* set AI_ADDRCONFIG. Document that people who
want to perform a literal IP translation - regardless of
connectivity - should use it.
E.g., if I want to turn "::1" into a structure I can use
and I totally don't care if I have general IPv6 connectivity
or if I even have connectivity to ::1 itself, I should use this
flag.

+1

[Joe Orton]

Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog

This is probably IPv6 related; does "modprobe ipv6" make a difference;
did 1.2.8 fail similarly?

Post by Lucian Adrian Grijincu
Still haven't checked if this is to be expected running ./test/testall

You'll get random failures if you run testall from outside the test
directory, yes.

joe

[William A. Rowe, Jr.]

Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.

Yow :(

would you try running within gdb and give us the where's? You might
need to recompile with CFLAGS=-g for debugging symbols.

Bill

[Lucian Adrian Grijincu]

Post by William A. Rowe, Jr.

Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.

Yow :(
would you try running within gdb and give us the where's? You might
need to recompile with CFLAGS=-g for debugging symbols.
Bill

Sorry,
I was sleepy and unattentive:
testall is supposed to be run from the test/ subdirectory.
I ran it as ./test/testall, with chdir being the apr directory, not
it's test subdir.

Nothing to see here, please move along :)

See my other mail: with the patch applied all tests succeed.
(still if I run testall from apr and not apr/test/ some tests fail,
but I think it's in the test design to be so).

--
Lucian Adrian Grijincu

[William A. Rowe, Jr.]

Post by William A. Rowe, Jr.
would you try running within gdb and give us the where's? You might
need to recompile with CFLAGS=-g for debugging symbols.

someday I'll learn to read forward to the end before clicking send on
the smaller random replies :) Nicely done with your diagnostics. On the
subject of apr - you need to cd test and then ./testall from within that
directory, just as 'make check' does.

[Joe Orton]

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9

These both show no regressions on Linux/i386 and x86_64.

w.r.t. APR_HAS_LARGE_FILES, please see list archives for rationale, it
is defined as intended; yes the testlfs error message is poor for the
!lfs case

joe

[Bojan Smojver]

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[+1] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

Fedora 7 i386 and x86_64.

PS. Thanks everyone for clearing up the APR_HAS_LARGE_FILES thing.

[William A. Rowe, Jr.]

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

We are at 2x +1 for apr 0.9.14 and apr 1.2.9

We are at no votes for apr-iconv 1.2.0.

It seems most of the concerns are addressed, and while worth addressing,
not necessary for this release.

Votes, please, folks? And while we are on the subject, note the subj
says [vote] - not [discuss] :) Please use appropriate subject renames
when you launch off on a tangent/report build failures.

Bill

[Sander Temme]

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9
[+1] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

FreeBSD 6.1 and 4.11, see below. +1 for release. Both FreeBSDs have
their (VMWare) interface configured with link-local IPv6 in addition
to IPv4.

S.


--------

All built with ./configure --prefix=something --enable-nonportable-
atomics

FreeBSD freebsd6.sandla.org. 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Wed
Nov 29 12:51:00 PST 2006 ***@freebsd6.sandla.org.:/usr/obj/usr/
src/sys/SMP amd64

This is a single CPU VMWare instance with 256Mb of memory on a dual
AMD64 Penguin Computing box.

Post by William A. Rowe, Jr.
This program won't work on this platform because there is no
support for threads.
This program won't work fully on this platform because there is no
support for threads.
Failed
oldval =0 should be zero
Failed.
testing apr_atomic_dec ***
Error code 255
Stop in /x1/sctemme/apr/build/apr-0.9.14/test.
*** Error code 1
Stop in /x1/sctemme/apr/build/apr-0.9.14.

AFAIK threads are OK in FreeBSD 6. No regression from 0.9.13.

apr-1.2.9 make check: All tests passed.
This died somewhere in or after the lock performance tests on 1.2.8

apr-iconv-1.2.0 has no make check target or discernable tests, and
neither did 1.1.1

FreeBSD freebsd4.sandla.org. 4.11-RELEASE FreeBSD 4.11-RELEASE #0:
Wed Nov 29 19:16:35 PST 2006 ***@freebsd4.sandla.org.:/usr/obj/
usr/src/sys/FREEBSD4 i386

apr-0.9.14: same failure as above
apr-1.2.9: All tests passed.

[William A. Rowe, Jr.]

Post by Sander Temme

Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9
[+1] apr-iconv-1.2.0
Three packages so far to consider, votes welcome

FreeBSD 6.1 and 4.11, see below. +1 for release. Both FreeBSDs have
their (VMWare) interface configured with link-local IPv6 in addition to
IPv4.

Thanks Sander.

That's +4 for apr's (+5 once I vote), +1 for apr-iconv (+2 once I vote).

I'll chime in and close this round of release votes once I have
one more +/- apr-iconv 1.2.0.

Bill

[William A. Rowe, Jr.]

Post by William A. Rowe, Jr.
That's +4 for apr's (+5 once I vote), +1 for apr-iconv (+2 once I vote).
I'll chime in and close this round of release votes once I have
one more +/- apr-iconv 1.2.0.

Ping?

[Bojan Smojver]

Post by William A. Rowe, Jr.
[+1] apr-iconv-1.2.0

Fedora 7, i386, builds against APR 1.2.9 (both against APR build tree
and installed APR).

One note, though. Without --prefix option to configure, the build fails
with:
-----------------------------------------------
/bin/sh /home/users/bojan/aa/apr-1.2.9/libtool --mode=link gcc -g -O2
-pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -I/home/users/bojan/aa/apr-iconv-1.2.0/lib
-I/home/users/bojan/aa/apr-iconv-1.2.0/include
-I/home/users/bojan/aa/apr-1.2.9/include -module -avoid-version -rpath
NONE/lib/iconv -o iso-8859-1.la iso-8859-1.lo
libtool: link: only absolute run-paths are allowed
-----------------------------------------------

Looks like default prefix was set to NONE (literally). Not sure if this
is intentional or not.

[William A. Rowe, Jr.]

Post by William A. Rowe, Jr.
[+1] apr-iconv-1.2.0

And +1 to all three packages, here.

I'm finally in one place, with connectivity, at last. I'll stage these
all up with updated web content tomorrow (and probably tackle placing
our status reports on the /dev/ site as well.)

Bill

[William A. Rowe, Jr.]

Post by Bojan Smojver

Post by William A. Rowe, Jr.
[+1] apr-iconv-1.2.0

Fedora 7, i386, builds against APR 1.2.9 (both against APR build tree
and installed APR).
One note, though. Without --prefix option to configure, the build fails
Looks like default prefix was set to NONE (literally). Not sure if this
is intentional or not.

Idea; should we default --prefix to the apr-1-config's prefix?

Bill