Bug #61577 for IO: ->sockdomain and ->socktype undefined on newly ->accept'ed sockets

Wed Sep 22 19:30:30 2010 leonerd-cpan [...] leonerd.org.uk - Ticket created

Subject:

->sockdomain and ->socktype undefined on newly ->accept'ed sockets

Given some socket in listening mode, $sock: my $new = $sock->accept; ok( defined $new->sockdomain ); ok( defined $new->socktype ); both fail. I have a workaround in my subclass, which involves: ----- sub accept { my $self = shift; my ( $new, $peer ) = $self->SUPER::accept or return; ${*$new}{$_} = ${*$self}{$_} for qw( io_socket_domain io_socket_type io_socket_proto ); return wantarray ? ( $new, $peer ) : $new; } ----- Could IO::Socket itself do this please? -- Paul Evans

Fri Dec 23 06:25:06 2011 SHLOMIF [...] cpan.org - Correspondence added

Hi, On Wed Sep 22 19:30:30 2010, PEVANS wrote: Show quoted text

> Given some socket in listening mode, $sock: > > my $new = $sock->accept; > > ok( defined $new->sockdomain ); > ok( defined $new->socktype ); > > both fail. > > I have a workaround in my subclass, which involves: > > ----- > sub accept > { > my $self = shift; > my ( $new, $peer ) = $self->SUPER::accept or return; > > ${*$new}{$_} = ${*$self}{$_} for qw( io_socket_domain io_socket_type > io_socket_proto ); > > return wantarray ? ( $new, $peer ) > : $new; > }

This also happens with new_from_fd / fdopen . Here is a testcase: [CODE] #!/usr/bin/perl use strict; use warnings; use IO::Socket::INET; my $sock = IO::Socket::INET->new( PeerAddr => 'www.perl.org', PeerPort => 'http(80)', Proto => 'tcp' ); print "Orig domain ==", $sock->sockdomain(), "\n"; my $dup_sock = IO::Socket::INET->new_from_fd($sock, '+<'); print "Dup domain ==", $dup_sock->sockdomain(), "\n"; [/CODE] This affected IO::Socket::INET6 in this bug report: https://rt.cpan.org/Public/Bug/Display.html?id=68282 Please correct it. Regards, -- Shlomi Fish Show quoted text

> ----- > > Could IO::Socket itself do this please?

Fri Dec 23 06:25:09 2011 The RT System itself - Status changed from 'new' to 'open'

Thu Feb 09 01:03:29 2012 dkg [...] fifthhorseman.net - Correspondence added

Subject:	[rt.cpan.org #61577] more robust patch to fix un-propagated cached details for IO::Socket objects
Date:	Thu, 09 Feb 2012 01:03:55 -0500
To:	bug-IO [...] rt.cpan.org, 659075 [...] bugs.debian.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

I think my earlier patch for CPAN's #61577 and debian #659075 only addressed the accept() case. This is a replacement. The attached patch should cover IO::Socket objects created via accept(), new_from_fd(), new(), and anywhere else whose details haven't been properly cached. No new code should be executed on IO::Socket objects whose details are already cached and present. If there are problems that would prevent this change from being accepted (either upstream or in debian), please let me know and i'll try to address them. Regards, --dkg

--- a/dist/IO/lib/IO/Socket.pm 2012-02-07 21:12:42.000000000 -0500 +++ b/dist/IO/lib/IO/Socket.pm 2012-02-09 00:54:14.000000000 -0500 @@ -336,18 +336,34 @@ sub sockdomain { @_ == 1 or croak 'usage: $sock->sockdomain()'; my $sock = shift; +# FIXME: SO_DOMAIN should probably ultimately be included in Socket.pm +# and the associated XS, but it isn't necessarily portable. see: +# https://mail.gnome.org/archives/commits-list/2011-September/msg00944.html + my $so_domain = 39; + if (!defined(${*$sock}{'io_socket_domain'})) { + my $addr = $sock->getsockname(); + if (defined($addr)) { + ${*$sock}{'io_socket_domain'} = sockaddr_family($addr); + } else { + ${*$sock}{'io_socket_domain'} = $sock->sockopt($so_domain) + } + } ${*$sock}{'io_socket_domain'}; } sub socktype { @_ == 1 or croak 'usage: $sock->socktype()'; my $sock = shift; + ${*$sock}{'io_socket_type'} = $sock->sockopt(SO_TYPE) + unless defined(${*$sock}{'io_socket_type'}); ${*$sock}{'io_socket_type'} } sub protocol { @_ == 1 or croak 'usage: $sock->protocol()'; my($sock) = @_; + ${*$sock}{'io_socket_proto'} = $sock->sockopt(SO_PROTOCOL) + unless defined(${*$sock}{'io_socket_proto'}); ${*$sock}{'io_socket_proto'}; }

Thu Feb 09 12:03:42 2012 dkg [...] fifthhorseman.net - Correspondence added

CC:	659075 [...] bugs.debian.org, bug-IO [...] rt.cpan.org
Subject:	Re: Bug#659075: [rt.cpan.org #61577] more robust patch to fix un-propagated cached details for IO::Socket objects
Date:	Thu, 09 Feb 2012 12:04:12 -0500
To:	perl5-porters [...] perl.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

Hi perl porters-- There appears to be a flaw in IO::Socket where some IO::Socket objects are unable to properly report their socktype, sockdomain, or protocol (they return undef, even when the underlying socket is sufficiently initialized to have these properties). The attached patch has been forwarded to CPAN's #61577 [0] and debian's #659075 [1], and should address these issues no matter why the cached details happen to be missing. I'd be happy to improve the patch somehow if you have any suggestions (you'll note that there's a FIXME in there because of SO_DOMAIN's general non-portability -- i'm not sure how you'd generally want to approach that sort of thing generally within perl, so i've gone for the narrowly-targeted fix instead of something more intrusive). I'm not subscribed to perl5-porters, so please CC me with any replies. Thanks for maintaining Perl! --dkg [0] https://rt.cpan.org/Ticket/Display.html?id=61577 [1] http://bugs.debian.org/659075

Message body is not shown because sender requested not to inline it.

Tue Feb 14 01:17:23 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

RT-Send-CC:

dkg [...] fifthhorseman.net, 659075 [...] bugs.debian.org, perl5-porters [...] perl.org

On Thu Feb 09 12:03:42 2012, dkg@fifthhorseman.net wrote: Show quoted text

> Hi perl porters-- > > There appears to be a flaw in IO::Socket where some IO::Socket objects > are unable to properly report their socktype, sockdomain, or protocol > (they return undef, even when the underlying socket is sufficiently > initialized to have these properties). > > The attached patch has been forwarded to CPAN's #61577 [0] and debian's > #659075 [1], and should address these issues no matter why the cached > details happen to be missing.

Is there any chance you could include tests cases, too?

Tue Feb 14 01:39:13 2012 659075 [...] bugs.debian.org - Correspondence added

Subject:	Bug#659075: Info received ([rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets )
Date:	Tue, 14 Feb 2012 06:39:05 +0000
To:	bug-IO [...] rt.cpan.org
From:	owner [...] bugs.debian.org (Debian Bug Tracking System)

Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Niko Tyni <ntyni@debian.org> If you wish to submit further information on this problem, please send it to 659075@bugs.debian.org. Please do not send mail to owner@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 659075: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659075 Debian Bug Tracking System Contact owner@bugs.debian.org with problems

Tue Feb 14 10:22:40 2012 leonerd-cpan [...] leonerd.org.uk - Correspondence added

RT-Send-CC:

dkg [...] fifthhorseman.net, perl5-porters [...] perl.org

I'm a little bit worried about this change. In my experience, SO_DOMAIN is far from reliable across platforms. Also, some operating systems omit it entirely but have instead an SO_FAMILY that does the same thing. (I've yet to meet an OS that had both, however). I think it's OK to optimistically /try/ to fill in the object slots using SO_DOMAIN/FAMILY/TYPE/PROTOCOL, but don't rely on them to necessarily yield an answer. -- Paul Evans

Tue Feb 14 11:16:54 2012 dkg [...] fifthhorseman.net - Correspondence added

CC:	perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Tue, 14 Feb 2012 11:16:36 -0500
To:	bug-IO [...] rt.cpan.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

On 02/14/2012 10:22 AM, Paul Evans via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=61577 > > > I'm a little bit worried about this change. > > In my experience, SO_DOMAIN is far from reliable across platforms. Also, > some operating systems omit it entirely but have instead an SO_FAMILY > that does the same thing. (I've yet to meet an OS that had both, > however). > > I think it's OK to optimistically /try/ to fill in the object slots using > SO_DOMAIN/FAMILY/TYPE/PROTOCOL, but don't rely on them to necessarily > yield an answer.

at the moment, we have scenarios where there is no attempt at all to yield an answer, and protocol, sockdomain, and socktype just return undefined. So the proposed workaround is a significant improvement anyway. Note that the proposed code to populate the domain parameter cache doesn't just use SO_DOMAIN; it tries getsockname() first (also apparently somewhat unportable), and then falls back to trying SO_DOMAIN if the earlier attempt fails. If there are platforms on which the proposed fix doesn't work on, i'd be happy to see patches for those platforms. but i don't think we should avoid fixing the platforms which do support these system calls. --dkg

Tue Feb 14 13:38:22 2012 dkg [...] fifthhorseman.net - Correspondence added

CC:	659075 [...] bugs.debian.org, perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Tue, 14 Feb 2012 13:38:07 -0500
To:	bug-IO [...] rt.cpan.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

On 02/14/2012 01:17 AM, Father Chrysostomos via RT wrote: Show quoted text

> Is there any chance you could include tests cases, too?

Ah yes, good call. This prompted me to find a bug in my patch as well (i was calling getsockname() instead of sockname() on the IO::Socket object, i have no idea how i missed that the first time through). A revised patch is attached. Also attached are three test cases that test unix domain sockets, TCP sockets, and UDP sockets. Each fails with the when run against an unpatched IO::Socket. With my v2 patch applied to IO::Socket, all tests pass for all three test cases. Regards, --dkg

Message body is not shown because sender requested not to inline it.

Tue Feb 14 13:55:00 2012 micah [...] riseup.net - Correspondence added

CC:	659075 [...] bugs.debian.org, perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Tue, 14 Feb 2012 13:54:48 -0500
To:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>, bug-IO [...] rt.cpan.org
From:	micah anderson <micah [...] riseup.net>

On Tue, 14 Feb 2012 13:38:07 -0500, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: Show quoted text

> On 02/14/2012 01:17 AM, Father Chrysostomos via RT wrote: >

> > Is there any chance you could include tests cases, too?

> > Ah yes, good call. This prompted me to find a bug in my patch as well > (i was calling getsockname() instead of sockname() on the IO::Socket > object, i have no idea how i missed that the first time through). > > A revised patch is attached.

I've just applied and tested this revised patch and can confirm that resolves the error(s) that I was seeing with this issue. micah

Tue Feb 14 15:58:56 2012 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Tue Feb 14 11:16:54 2012, dkg@fifthhorseman.net wrote: Show quoted text

> So the proposed workaround is a significant improvement anyway. > > Note that the proposed code to populate the domain parameter cache > doesn't just use SO_DOMAIN; it tries getsockname() first (also > apparently somewhat unportable), and then falls back to trying SO_DOMAIN > if the earlier attempt fails. > > If there are platforms on which the proposed fix doesn't work on, i'd be > happy to see patches for those platforms. but i don't think we should > avoid fixing the platforms which do support these system calls.

I'm not too happy about this patch currently, because it just "guesses" that sockopt 38 is SO_DOMAIN. I'm aware that Socket doesn't currently wrap SO_DOMAIN, and I'm happy to add that. The trouble is that there's a small chance some other OS has a different sockopt at 38, and this could lead to the wrong answer. Until then, though I'd suggest just sticking to sockaddr_family() of getsockname() - that ought to be reliable enough I should think. Since SO_TYPE and SO_PROTOCOL come from Socket, those should pose no problem. If they work, they work, if not they don't. It's a little too close to perl 5.16 feature-freeze to consider adding SO_DOMAIN to Socket now, however, as I am hoping to get the current 1.97_002 tested in time to call it 1.98, but once that's done I'll add SO_DOMAIN / SO_FAMILY, and let you know. -- Paul Evans

Thu Feb 16 00:18:27 2012 dkg [...] fifthhorseman.net - Correspondence added

CC:	perl5-porters [...] perl.org, 659075 [...] bugs.debian.org
Subject:	Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Thu, 16 Feb 2012 00:18:03 -0500
To:	bug-IO [...] rt.cpan.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

leonerd-cpan@leonerd.org.uk wrote: Show quoted text

> I'm not too happy about this patch currently, because it just > "guesses" that sockopt 38 is SO_DOMAIN. I'm aware that Socket doesn't > currently wrap SO_DOMAIN, and I'm happy to add that. The trouble is > that there's a small chance some other OS has a different sockopt at > 38, and this could lead to the wrong answer.

i'm pretty sure you mean 39 here, and not 38. :) I grabbed that value From the Linux headers on my debian system, and upon a wider review, you're absolutely right that this was inappropriate: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/socket.h#SO_DOMAIN I'm attaching a revised, simplified patch that doesn't make this non-portable assumption. On a Debian GNU/Linux wheezy (testing) system right now, it still passes all tests. Show quoted text

> Until then, though I'd suggest just sticking to sockaddr_family() of > getsockname() - that ought to be reliable enough I should think.

https://mail.gnome.org/archives/commits-list/2011-September/msg00944.html suggests that on Solaris, if the socket isn't connected, getsockname() (i.e. Socket::->sockname()) will return an addrlen of 0 and not set the sockaddr. So in that situation, we'll at least be no worse off than the current implementation, which seems reasonable. Debian folks -- is this now a patch that folks feel comfortable applying in anticipation of such a fix upstream? --dkg

--- a/dist/IO/lib/IO/Socket.pm +++ b/dist/IO/lib/IO/Socket.pm @@ -336,18 +336,27 @@ sub sockdomain { @_ == 1 or croak 'usage: $sock->sockdomain()'; my $sock = shift; + if (!defined(${*$sock}{'io_socket_domain'})) { + my $addr = $sock->sockname(); + ${*$sock}{'io_socket_domain'} = sockaddr_family($addr) + if (defined($addr)); + } ${*$sock}{'io_socket_domain'}; } sub socktype { @_ == 1 or croak 'usage: $sock->socktype()'; my $sock = shift; + ${*$sock}{'io_socket_type'} = $sock->sockopt(SO_TYPE) + unless defined(${*$sock}{'io_socket_type'}); ${*$sock}{'io_socket_type'} } sub protocol { @_ == 1 or croak 'usage: $sock->protocol()'; my($sock) = @_; + ${*$sock}{'io_socket_proto'} = $sock->sockopt(SO_PROTOCOL) + unless defined(${*$sock}{'io_socket_proto'}); ${*$sock}{'io_socket_proto'}; }

Download (untitled)
application/pgp-signature 965b

Message body not shown because it is not plain text.

Thu Feb 16 19:22:23 2012 dkg [...] fifthhorseman.net - Correspondence added

CC:	perl5-porters [...] perl.org, 659075 [...] bugs.debian.org
Subject:	Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Thu, 16 Feb 2012 19:22:05 -0500
To:	bug-IO [...] rt.cpan.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

On Thu, 16 Feb 2012 00:18:03 -0500, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: Show quoted text

> I'm attaching a revised, simplified patch that doesn't make this > non-portable assumption. On a Debian GNU/Linux wheezy (testing) system > right now, it still passes all tests.

Sigh. I tried the -v3 patch on a FreeBSD system (which doesn't have SO_PROTOCOL defined, apparently), and on such a system, the tests fail hard (perl process terminates with return code 29) with the following message: Your vendor has not defined Socket macro SO_PROTOCOL, used at /usr/lib/perl/5.14/IO/Socket.pm line 359 This is bad, and probably worse than just returning undefined as it has up til now. The attached patch (v4) should behave no worse than the existing misbehavior on systems where SO_PROTOCOL (or SO_TYPE) is not defined by the OS, while still re-populating missing cached data on operating systems that do provide these sockopts. Regards, --dkg

--- a/dist/IO/lib/IO/Socket.pm +++ b/dist/IO/lib/IO/Socket.pm @@ -336,18 +336,27 @@ sub sockdomain { @_ == 1 or croak 'usage: $sock->sockdomain()'; my $sock = shift; + if (!defined(${*$sock}{'io_socket_domain'})) { + my $addr = $sock->sockname(); + ${*$sock}{'io_socket_domain'} = sockaddr_family($addr) + if (defined($addr)); + } ${*$sock}{'io_socket_domain'}; } sub socktype { @_ == 1 or croak 'usage: $sock->socktype()'; my $sock = shift; + ${*$sock}{'io_socket_type'} = $sock->sockopt(Socket::SO_TYPE) + if (!defined(${*$sock}{'io_socket_type'}) && defined(eval{Socket::SO_TYPE})); ${*$sock}{'io_socket_type'} } sub protocol { @_ == 1 or croak 'usage: $sock->protocol()'; my($sock) = @_; + ${*$sock}{'io_socket_proto'} = $sock->sockopt(Socket::SO_PROTOCOL) + if (!defined(${*$sock}{'io_socket_proto'}) && defined(eval{Socket::SO_PROTOCOL})); ${*$sock}{'io_socket_proto'}; }

Thu Feb 16 19:25:44 2012 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Tue Feb 14 15:58:56 2012, PEVANS wrote: Show quoted text

> It's a little too close to perl 5.16 feature-freeze to consider adding > SO_DOMAIN to Socket now, however, as I am hoping to get the current > 1.97_002 > tested in time to call it 1.98, but once that's done I'll add > SO_DOMAIN / > SO_FAMILY, and let you know.

1.98_001 now on CPAN. Contains SO_DOMAIN. SO_FAMILY was already provided. -- Paul Evans

Fri Feb 17 17:33:27 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

RT-Send-CC:

dkg [...] fifthhorseman.net, perl5-porters [...] perl.org

On Thu Feb 16 19:22:23 2012, dkg@fifthhorseman.net wrote: Show quoted text

> On Thu, 16 Feb 2012 00:18:03 -0500, Daniel Kahn Gillmor > <dkg@fifthhorseman.net> wrote:

> > I'm attaching a revised, simplified patch that doesn't make this > > non-portable assumption. On a Debian GNU/Linux wheezy (testing)

> system

> > right now, it still passes all tests.

> > Sigh. I tried the -v3 patch on a FreeBSD system (which doesn't have > SO_PROTOCOL defined, apparently), and on such a system, the tests fail > hard (perl process terminates with return code 29) with the following > message: > > Your vendor has not defined Socket macro SO_PROTOCOL, used at > /usr/lib/perl/5.14/IO/Socket.pm line 359 > > This is bad, and probably worse than just returning undefined as it > has > up til now. > > The attached patch (v4) should behave no worse than the existing > misbehavior on systems where SO_PROTOCOL (or SO_TYPE) is not defined > by > the OS, while still re-populating missing cached data on operating > systems that do provide these sockopts. > > Regards, > > --dkg

I’ve pushed your patches to the smoke-me/cpan61577 branch at perl5.git.perl.org.

Sat Feb 18 14:15:09 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

RT-Send-CC:

dkg [...] fifthhorseman.net, perl5-porters [...] perl.org

On Fri Feb 17 17:33:27 2012, SPROUT wrote: Show quoted text

> On Thu Feb 16 19:22:23 2012, dkg@fifthhorseman.net wrote:

> > On Thu, 16 Feb 2012 00:18:03 -0500, Daniel Kahn Gillmor > > <dkg@fifthhorseman.net> wrote:

> > > I'm attaching a revised, simplified patch that doesn't make this > > > non-portable assumption. On a Debian GNU/Linux wheezy (testing)

> > system

> > > right now, it still passes all tests.

> > > > Sigh. I tried the -v3 patch on a FreeBSD system (which doesn't have > > SO_PROTOCOL defined, apparently), and on such a system, the tests

> fail

> > hard (perl process terminates with return code 29) with the

> following

> > message: > > > > Your vendor has not defined Socket macro SO_PROTOCOL, used at > > /usr/lib/perl/5.14/IO/Socket.pm line 359 > > > > This is bad, and probably worse than just returning undefined as it > > has > > up til now. > > > > The attached patch (v4) should behave no worse than the existing > > misbehavior on systems where SO_PROTOCOL (or SO_TYPE) is not defined > > by > > the OS, while still re-populating missing cached data on operating > > systems that do provide these sockopts. > > > > Regards, > > > > --dkg

> > I’ve pushed your patches to the smoke-me/cpan61577 branch at > perl5.git.perl.org.

These tests are not passing for me on darwin: Pint:perl.git sprout$ ./perl -Ilib dist/IO/t/cachepropagate-tcp.t 1..8 # Running under perl version 5.015007 for darwin # Current time local: Sat Feb 18 11:13:49 2012 # Current time GMT: Sat Feb 18 19:13:49 2012 # Using Test.pm version 1.25_02 ok 1 ok 2 ok 3 ok 4 ok 5 ok 5 not ok 6 # Test 6 got: <UNDEF> (dist/IO/t/cachepropagate-tcp.t at line 39) # Expected: "6" # dist/IO/t/cachepropagate-tcp.t line 39 is: ok($new->protocol(), $p); ok 7 ok 8 Pint:perl.git sprout$ ./perl -Ilib dist/IO/t/cachepropagate-udp.t 1..7 # Running under perl version 5.015007 for darwin # Current time local: Sat Feb 18 11:13:59 2012 # Current time GMT: Sat Feb 18 19:13:59 2012 # Using Test.pm version 1.25_02 ok 1 ok 2 ok 3 ok 4 not ok 5 # Test 5 got: <UNDEF> (dist/IO/t/cachepropagate-udp.t at line 25) # Expected: "17" # dist/IO/t/cachepropagate-udp.t line 25 is: ok($new->protocol(), $p); ok 6 ok 7 Pint:perl.git sprout$ ./perl -Ilib dist/IO/t/cachepropagate-unix.t 1..15 # Running under perl version 5.015007 for darwin # Current time local: Sat Feb 18 11:14:05 2012 # Current time GMT: Sat Feb 18 19:14:05 2012 # Using Test.pm version 1.25_02 ok 1 ok 2 ok 3 ok 4 ok 5 ok 5 not ok 6 # Test 6 got: <UNDEF> (dist/IO/t/cachepropagate-unix.t at line 39) # Expected: "0" # dist/IO/t/cachepropagate-unix.t line 39 is: ok($new->protocol(), $p); ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 not ok 13 # Test 13 got: <UNDEF> (dist/IO/t/cachepropagate-unix.t at line 61) # Expected: "0" # dist/IO/t/cachepropagate-unix.t line 61 is: ok($new->protocol(), $p); ok 14 ok 15 Summary of my perl5 (revision 5 version 15 subversion 7) configuration: Derived from: c72a6582fd80cdcf24404819bef6101cdfb4f1c4 Ancestor: a0ee90d6275e8e8ed2d2366771ed2111c3dc870d Platform: osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0: fri nov 5 23:20:39 pdt 2010; root:xnu-1504.9.17~1release_i386 i386 ' config_args='-de -Dusedevel -DDEBUGGING -Duseithreads -Dmad' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -DDEBUGGING -fno-strict-aliasing - pipe -fstack-protector -I/usr/local/include', optimize='-O3 -g', cppflags='-fno-common -DPERL_DARWIN -DDEBUGGING -fno-strict-aliasing -pipe - fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector - L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack- protector' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MAD PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_TRACK_MEMPOOL PERL_USE_DEVEL USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Locally applied patches: uncommitted-changes c72a6582fd80cdcf24404819bef6101cdfb4f1c4 Built under darwin Compiled at Feb 17 2012 14:40:56 @INC: lib /usr/local/lib/perl5/site_perl/5.15.7/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.15.7 /usr/local/lib/perl5/5.15.7/darwin-thread-multi-2level /usr/local/lib/perl5/5.15.7 /usr/local/lib/perl5/site_perl .

Sun Feb 19 18:25:58 2012 dkg [...] fifthhorseman.net - Correspondence added

CC:	perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Sun, 19 Feb 2012 18:25:52 -0500
To:	bug-IO [...] rt.cpan.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

On 02/18/2012 02:15 PM, Father Chrysostomos via RT wrote: Show quoted text

> These tests are not passing for me on darwin: > > Pint:perl.git sprout$ ./perl -Ilib dist/IO/t/cachepropagate-tcp.t

[...] Show quoted text

> not ok 6 > # Test 6 got: <UNDEF> (dist/IO/t/cachepropagate-tcp.t at line 39) > # Expected: "6" > # dist/IO/t/cachepropagate-tcp.t line 39 is: ok($new->protocol(), $p);

[...] Show quoted text

> Pint:perl.git sprout$ ./perl -Ilib dist/IO/t/cachepropagate-udp.t

[...] Show quoted text

> not ok 5 > # Test 5 got: <UNDEF> (dist/IO/t/cachepropagate-udp.t at line 25) > # Expected: "17" > # dist/IO/t/cachepropagate-udp.t line 25 is: ok($new->protocol(), $p);

[...] Show quoted text

> Pint:perl.git sprout$ ./perl -Ilib dist/IO/t/cachepropagate-unix.t

[...] Show quoted text

> not ok 6 > # Test 6 got: <UNDEF> (dist/IO/t/cachepropagate-unix.t at line 39) > # Expected: "0" > # dist/IO/t/cachepropagate-unix.t line 39 is: ok($new->protocol(), $p);

[...] Show quoted text

> not ok 13 > # Test 13 got: <UNDEF> (dist/IO/t/cachepropagate-unix.t at line 61) > # Expected: "0" > # dist/IO/t/cachepropagate-unix.t line 61 is: ok($new->protocol(), $p);

This indicates that darwin does not have SO_PROTOCOL defined. The number of failed tests with the patch should be less than the number of failed tests without the patch, but on systems with no SO_PROTOCOL or SO_TYPE defined in Socket, some of the tests will still fail. Perhaps a porter familiar with Darwin wants to propose a way to request the protocol identifier for a given socket? Would perl's development approach need such a fix (for darwin and other no-SO_PROTOCOL architectures) in order to accept the patchset upstream even though it fixes a bunch of failures on many architectures? --dkg

Sun Feb 19 19:11:15 2012 leonerd-cpan [...] leonerd.org.uk - Correspondence added

By the way, a far simply way to solve this entire problem is just to copy the values from the parent socket at ->accept time: https://metacpan.org/source/PEVANS/IO-Socket-IP-0.08/lib/IO/Socket/IP.pm#L655 -- Paul Evans

Sun Feb 19 19:11:58 2012 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Sun Feb 19 19:11:15 2012, PEVANS wrote: Show quoted text

> By the way, a far simply way to solve this entire problem is just to > copy the values from the parent socket at ->accept time: > > https://metacpan.org/source/PEVANS/IO-Socket-IP- > 0.08/lib/IO/Socket/IP.pm#L655

Or, since that link didn't quite work properly: sub accept { my $self = shift; my ( $new, $peer ) = $self->SUPER::accept or return; ${*$new}{$_} = ${*$self}{$_} for qw( io_socket_domain io_socket_type io_socket_proto ); return wantarray ? ( $new, $peer ) : $new; } -- Paul Evans

Fri Feb 24 15:11:50 2012 DKG [...] cpan.org - Correspondence added

On Sun Feb 19 19:11:15 2012, PEVANS wrote: Show quoted text

> By the way, a far simply way to solve this entire problem is just to > copy the values from the parent socket at ->accept time: > > https://metacpan.org/source/PEVANS/IO-Socket-IP- > 0.08/lib/IO/Socket/IP.pm#L655

Unfortunately, the problem isn't just caused by accept(). there are several other ways that these values can fail to propagate (e.g. new_from_fd(), etc), and not all of them are fixable in the way you describe.

Tue Feb 28 12:55:43 2012 dkg [...] fifthhorseman.net - Correspondence added

CC:	perl5-porters [...] perl.org
Subject:	Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Tue, 28 Feb 2012 12:55:55 -0500
To:	bug-IO [...] rt.cpan.org
From:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>

On Sun, 19 Feb 2012 18:25:52 -0500, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: Show quoted text

> This indicates that darwin does not have SO_PROTOCOL defined. The > number of failed tests with the patch should be less than the number of > failed tests without the patch, but on systems with no SO_PROTOCOL or > SO_TYPE defined in Socket, some of the tests will still fail.

As i noted earlier, this same failure will happen with FreeBSD since it does not define SO_PROTOCOL either. However, i just learned that FreeBSD is about to get SO_PROTOCOL: http://www.freebsd.org/cgi/query-pr.cgi?pr=162352 Show quoted text

> Perhaps a porter familiar with Darwin wants to propose a way to request > the protocol identifier for a given socket?

This question is still outstanding. I don't have a Darwin machine to experiment with. Can we get these fixes into IO::Socket? --dkg

Download (untitled)
application/pgp-signature 965b

Message body not shown because it is not plain text.

Sat Apr 07 05:51:27 2012 intrigeri [...] boum.org - Correspondence added

CC:	659075 [...] bugs.debian.org, bug-IO [...] rt.cpan.org, perl5-porters [...] perl.org
Subject:	Re: Bug#659075: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Date:	Sat, 07 Apr 2012 11:51:08 +0200
To:	Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>
From:	intrigeri <intrigeri [...] boum.org>

Hi, I confirm Daniel's v4 patch fixes Debian#607674 and RT#68282 for me, and eventually allows me to run a recent Net::Server. Thanks, Daniel, for your persistence in getting this bug fixed both upstream and in Debian. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

Wed May 02 18:35:55 2012 dom [...] cpan.org - Correspondence added

This is also https://rt.perl.org/rt3/Ticket/Display.html?id=112736 created since IO::Socket is core-maintained.

Thu May 10 15:45:19 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

This is resolved by perl commits 271d04eee, b6903614d and 01b71c89216. But I don’t have permission to mark it as such.

Thu Apr 19 18:37:00 2018 TODDR [...] cpan.org - Correspondence added

Ticket migrated to github as https://github.com/toddr/IO/issues/40

Thu Apr 19 18:37:00 2018 TODDR [...] cpan.org - Status changed from 'open' to 'resolved'