You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/06/05 00:49:43 UTC
[Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
> 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.
--
Bojan
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Davi Arnaut wrote:
> William A. Rowe, Jr. wrote:
>
>> 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.
> 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
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
William A. Rowe, Jr. wrote:
> Davi Arnaut wrote:
>> Bojan Smojver wrote:
>>> On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote:
>>>
>>>> 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.
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Davi Arnaut wrote:
> Bojan Smojver wrote:
>> On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote:
>>
>>> 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.
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
Bojan Smojver wrote:
> On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote:
>
>> 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);
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote:
> testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying "these things are enabled by
default on this platform"?
--
Bojan
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 6/4/2007 at 4:49 PM, in message <46...@rowe-clan.net>, "William
A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
> On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
>
>> [+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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
> On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
>
>> [+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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2007-06-04 at 17:49 -0500, William A. Rowe, Jr. wrote:
> [+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.
--
Bojan
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Jun 04, 2007 at 05:49:43PM -0500, William Rowe wrote:
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> 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?
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sander Temme wrote:
>
> On Jun 4, 2007, at 3:49 PM, William A. Rowe, Jr. wrote:
>
>> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Sander Temme <sc...@apache.org>.
On Jun 4, 2007, at 3:49 PM, William A. Rowe, Jr. wrote:
> 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 root@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.
apr-0.9.14 make check:
> 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 root@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.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Gringo Croco <gr...@gmail.com>.
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
On 6/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 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
>
>
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> 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.
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/7/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> > 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.
>
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
> 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.
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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jun 06, 2007 at 11:40:41AM +0300, Lucian Adrian Grijincu wrote:
> 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
This is probably IPv6 related; does "modprobe ipv6" make a difference;
did 1.2.8 fail similarly?
> Also:
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
Colm MacCarthaigh wrote:
> On Wed, Jun 06, 2007 at 06:36:52PM -0500, William A. Rowe, Jr. wrote:
>> +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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Jun 06, 2007 at 06:36:52PM -0500, William A. Rowe, Jr. wrote:
> +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 :-)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Colm MacCarthaigh wrote:
>
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Jun 06, 2007 at 01:39:52PM -0300, Davi Arnaut wrote:
> > 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}
> >
>
> 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 :-)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
Lucian Adrian Grijincu wrote:
> 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}
>
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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> 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.
> 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?
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jun 07, 2007 at 12:03:03AM +0200, Ruediger Pluem wrote:
> On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
> > 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
Re: Adding a source .c
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 6/6/2007 at 6:48 PM, in message <46...@rowe-clan.net>, "William
A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
>>
>> 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/%3c4d45da0507051
> 61718l54f7b079h83ade8a3cc19751c@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.
>
> 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.
Re: Adding a source .c
Posted by Davi Arnaut <da...@haxent.com.br>.
On 06/06/2007, at 21:48, William A. Rowe, Jr. wrote:
> Lucian Adrian Grijincu wrote:
>>
>> 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/%
>> 3c4d45da050705161718l54f7b079h83ade8a3cc19751c@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.
>
Clueless question: Would it be better to use ftw() (or nftw(), or fts
()) for traversing?
--
Davi Arnaut
Adding a source .c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
>
> 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/%3c4d45da050705161718l54f7b079h83ade8a3cc19751c@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.
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).
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/7/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> >
> > 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.
>
> 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.
>
> > 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 :)
>
> 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) {
---
> 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/%3c4d45da050705161718l54f7b079h83ade8a3cc19751c@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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/07/2007 12:10 AM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>
>>On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
>>
>>
>>>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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
>
>> 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.
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/06/2007 11:45 PM, William A. Rowe, Jr. wrote:
>
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
>
> 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.
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.
> 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 :)
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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Jun 07, 2007 at 03:38:39AM +0300, Lucian Adrian Grijincu wrote:
> 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 :-)
> >> 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).
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/7/07, Colm MacCarthaigh <co...@stdlib.net> wrote:
> On Thu, Jun 07, 2007 at 03:06:10AM +0300, Lucian Adrian Grijincu wrote:
> > 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.
>
> > 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.)
>
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?
>
> > 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.
>
> --
> Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
>
--
Lucian Adrian Grijincu
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Jun 07, 2007 at 03:06:10AM +0300, Lucian Adrian Grijincu wrote:
> 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.
> 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.)
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 MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/7/07, Colm MacCarthaigh <co...@stdlib.net> wrote:
> On Thu, Jun 07, 2007 at 02:06:49AM +0300, Lucian Adrian Grijincu wrote:
> > <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
> 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 MacCárthaigh Public Key: colm+pgp@stdlib.net
>
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Jun 07, 2007 at 02:06:49AM +0300, Lucian Adrian Grijincu wrote:
> <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 MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Jeff Trawick <tr...@gmail.com>.
On 6/6/07, Colm MacCarthaigh <co...@stdlib.net> wrote:
> On Thu, Jun 07, 2007 at 12:24:07AM +0300, Lucian Adrian Grijincu wrote:
> > 1. kill AI_ADDRCONFIG for APR_UNSPEC
>
> In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
> unneccessary delay and lookups.
+1
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/7/07, Colm MacCarthaigh <co...@stdlib.net> wrote:
> On Thu, Jun 07, 2007 at 12:24:07AM +0300, Lucian Adrian Grijincu wrote:
> > 1. kill AI_ADDRCONFIG for APR_UNSPEC
>
> In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
> unneccessary delay and lookups.
>
> > 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.
>
> > 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 MacCárthaigh Public Key: colm+pgp@stdlib.net
>
<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.
--
Lucian Adrian Grijincu
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Jun 07, 2007 at 12:24:07AM +0300, Lucian Adrian Grijincu wrote:
> 1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
> 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.
> 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 MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/6/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> On 6/6/07, Davi Arnaut <da...@haxent.com.br> wrote:
> > Joe Orton wrote:
> > > On Wed, Jun 06, 2007 at 06:06:44PM +0300, Lucian Adrian Grijincu wrote:
> > >> $>./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?
> > >
> >
>
>
> u@h:~$ lsmod | grep ipv6
> ipv6 268960 12
>
> I guess 2.5 :)
> Ubuntu reports it as 2.5-0ubuntu14
>
> u@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.
>
>
>
> > 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.
>
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
Re: getaddrinfo on Ubuntu
Posted by Tollef Fog Heen <tf...@err.no>.
* 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.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: getaddrinfo on Ubuntu
Posted by Davi Arnaut <da...@haxent.com.br>.
Davi Arnaut wrote:
> Joe Orton wrote:
>> On Wed, Jun 06, 2007 at 10:57:00PM +0300, Lucian Adrian Grijincu wrote:
>>> This is the output:
>>> 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
>
>
Solaris:
[akojima@sunfire280 x]$ ./gai ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0}) = 0:
family=26, proto= 0 inet6: addr=::1, port=0, flowinfo=0
[akojima@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
[akojima@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
[akojima@sunfire280 x]$ ./gai -a ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG}) = 0:
Re: getaddrinfo on Ubuntu
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/7/07, Joe Orton <jo...@redhat.com> wrote:
> On Wed, Jun 06, 2007 at 08:15:49PM -0300, Davi Arnaut wrote:
> > Same machine, now with -n:
>
> 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.
> 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
Re: getaddrinfo on Ubuntu
Posted by Davi Arnaut <da...@haxent.com.br>.
Joe Orton wrote:
> On Wed, Jun 06, 2007 at 08:15:49PM -0300, Davi Arnaut wrote:
>> Same machine, now with -n:
>
> 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.
> 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
Re: getaddrinfo on Ubuntu
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jun 06, 2007 at 08:15:49PM -0300, Davi Arnaut wrote:
> Same machine, now with -n:
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
Re: getaddrinfo on Ubuntu
Posted by Davi Arnaut <da...@haxent.com.br>.
On 06/06/2007, at 19:06, Davi Arnaut wrote:
> Joe Orton wrote:
>> On Wed, Jun 06, 2007 at 10:57:00PM +0300, Lucian Adrian Grijincu
>> wrote:
>>> This is the output:
>>> 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
>
>
> Ubuntu 7.04 (no ipv6 addresses -- other then loopback -- configured):
>
> davi@karmic:~/gai$ make gai
> cc gai.c -o gai
> davi@karmic:~/gai$ ./gai ::1
> getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0}) = 0:
> family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
> davi@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
> davi@karmic:~/gai$ ./gai -a ::1
> getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|
> AI_ADDRCONFIG}) = -1:
> error: Address family for hostname not supported
> davi@karmic:~/gai$ ./gai -a ::1 null inet6
> getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|
> AI_ADDRCONFIG}) = -1:
> error: Name or service not known
>
Same machine, now with -n:
davi@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
davi@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
davi@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
davi@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
Re: getaddrinfo on Ubuntu
Posted by Davi Arnaut <da...@haxent.com.br>.
Joe Orton wrote:
> On Wed, Jun 06, 2007 at 10:57:00PM +0300, Lucian Adrian Grijincu wrote:
>> This is the output:
>> 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
Ubuntu 7.04 (no ipv6 addresses -- other then loopback -- configured):
davi@karmic:~/gai$ make gai
cc gai.c -o gai
davi@karmic:~/gai$ ./gai ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0}) = 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
davi@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
davi@karmic:~/gai$ ./gai -a ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = -1:
error: Address family for hostname not supported
davi@karmic:~/gai$ ./gai -a ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG}) = -1:
error: Name or service not known
> 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
Re: getaddrinfo on Ubuntu
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Jun 06, 2007 at 10:18:41PM +0100, Joe Orton wrote:
> On Wed, Jun 06, 2007 at 10:57:00PM +0300, Lucian Adrian Grijincu wrote:
> > This is the output:
> > 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
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.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
getaddrinfo on Ubuntu
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jun 06, 2007 at 10:57:00PM +0300, Lucian Adrian Grijincu wrote:
> This is the output:
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On 6/6/07, Davi Arnaut <da...@haxent.com.br> wrote:
> Joe Orton wrote:
> > On Wed, Jun 06, 2007 at 06:06:44PM +0300, Lucian Adrian Grijincu wrote:
> >> $>./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?
> >
>
u@h:~$ lsmod | grep ipv6
ipv6 268960 12
I guess 2.5 :)
Ubuntu reports it as 2.5-0ubuntu14
u@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.
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
Joe Orton wrote:
> On Wed, Jun 06, 2007 at 06:06:44PM +0300, Lucian Adrian Grijincu wrote:
>> $>./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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jun 06, 2007 at 06:06:44PM +0300, Lucian Adrian Grijincu wrote:
> $>./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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Davi Arnaut wrote:
>
> See my email about it, message id <46...@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).
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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Jun 06, 2007 at 08:49:06PM -0300, Davi Arnaut wrote:
> > 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?
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 :-)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
Colm MacCarthaigh wrote:
> On Wed, Jun 06, 2007 at 08:32:12PM -0300, Davi Arnaut wrote:
>> /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.
>
> 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.
>
>> /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
>
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Jun 06, 2007 at 08:32:12PM -0300, Davi Arnaut wrote:
> /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.
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.
> /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
Why wouldn't that fail?
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
Colm MacCarthaigh wrote:
> On Wed, Jun 06, 2007 at 03:05:17PM -0300, Davi Arnaut wrote:
>> 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.
>
> 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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Jun 06, 2007 at 03:05:17PM -0300, Davi Arnaut wrote:
> 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.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Davi Arnaut <da...@haxent.com.br>.
Lucian Adrian Grijincu wrote:
> 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 )
>
<snip>
>
> 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 <46...@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
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
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
On 6/6/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> 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
>
>
> On 6/6/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> > 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.
> >
> > On 6/6/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > > 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?
> > >
> > > Lucian Adrian Grijincu wrote:
> > > > 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
> > > >
> > > > On 6/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > > >> 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
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
>
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
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
On 6/6/07, Lucian Adrian Grijincu <lu...@gmail.com> wrote:
> 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.
>
> On 6/6/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > 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?
> >
> > Lucian Adrian Grijincu wrote:
> > > 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
> > >
> > > On 6/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> > >> 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
> > >>
> > >>
> > >
> > >
> >
>
Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
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.
On 6/6/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 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?
>
> Lucian Adrian Grijincu wrote:
> > 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
> >
> > On 6/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> >> 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
> >>
> >>
> >
> >
>