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
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.
--
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
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
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
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
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
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
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
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
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 |
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
Hi all,
I'm running Tomcat 6.0.10 with apr/apr-util 1.2.8, tomcat-native 1.1.8,
and JDK 1.6.0_01 (6u1), SSL, i686, CentOS 4.5.
It seems that every time I shutdown tomcat, the JVM crashes with a
segfault, and looking at the dump I'm wondering if it might be
apr-related.
It also happens on my
On 6/6/07, Davi Arnaut [EMAIL PROTECTED] 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
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
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 :
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
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
Davi Arnaut wrote:
See my email about it, message id [EMAIL PROTECTED]
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
On 6/7/07, William A. Rowe, Jr. [EMAIL PROTECTED] 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
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
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
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
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
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
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
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
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
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
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
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
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.,
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
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
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
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
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
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
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
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
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
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/[EMAIL PROTECTED]
included in APR. It's been
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,
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:
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 :-)
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2007-06-04 18:01:31 -0400 (Mon, 04 Jun 2007) $]
Releases:
1.3.0 : in development
1.2.10: in maintenance
1.2.9 : tagged June 4, 2007
1.2.8 : released December 4, 2006
APACHE PORTABLE RUNTIME UTILITIES (APR-util) LIBRARY STATUS:-*-text-*-
Last modified at [$Date: 2007-02-16 21:50:17 -0500 (Fri, 16 Feb 2007) $]
Releases:
1.3.0 : in development
1.2.9 : in development
1.2.8 : released December 4, 2006
1.2.7 : released April 14,
47 matches
Mail list logo