While writing a test on work I hit a bug in perl. Normally if recv is interrupted by a signal it returns undef and sets $! to EINTR. In my case I had failure because $! was set to zero. It took me some time to reproduce conditions in which it happens, but finally I've got it boiled down to the following:

use strict;
use warnings;
use IO::Socket::INET;

my $srv = IO::Socket::INET->new(
    LocalAddr => '127.0.0.1',
    LocalPort => 7777,
    ReuseAddr => 1,
    Listen    => 1,
) or die $!;

my $sock = IO::Socket::INET->new(
    PeerAddr => '127.0.0.1',
    PeerPort => 7777,
) or die $!;
my $cli = $srv->accept or die $!;

my $sock2 = IO::Socket::INET->new(
    PeerAddr => '127.0.0.1',
    PeerPort => 7777,
) or die $!;
my $cli2 = $srv->accept or die $!;

local $SIG{ALRM} = sub { $sock->send( "hi\n", 0 ); };

alarm 2;

my $res;
use Data::Dumper;
$res = $sock2->recv( my $buf, 1024 ) or die Dumper [ $res, $!, 0 + $!,
+ ];
__END__
$VAR1 = [
          undef,
          '',
          '0'
        ];

[download]

The trick was to establish two connections to the same peer, with only one connection I was getting correct result. Apparently this was fixed somewhere in 5.13, because if I run this with 5.14.2 it returns expected result, which is: 

$VAR1 = [
          undef,
          'Interrupted system call',
          '4'
        ];

[download]

That's the downside of using stable Debian -- you're hitting bugs that were already found and fixed years ago. I couldn't find it in RT though, so if somebody by any chance know what I'm talking about and can point me to the ticket or commit in git it would be much appreciated. I naturally fixed the problem in my module with: 

         my $ret = $self->{_socket}->recv( my $buffer, 131072 );
         unless ( defined $ret ) {
-            next if $! == EINTR;
+            next if $! == EINTR or $! == 0;
             confess "Error reading reply from server: $!";
         }

[download]
But now I have some doubts -- maybe recv sets $! to 0 for some other errors too.

Update: for the record, the commit that fixes the problem is d016601

Replies are listed 'Best First'.
Re: Rediscovering fixed bugs
by Tanktalus (Canon) on Oct 12, 2012 at 00:57 UTC

    This is a major reason why I'm trying to put together my own pseudo-distribution of Perl for $work and redistribute that. Then I'm not beholden to the level of Perl on the OS we end up deploying on (currently AIX 6 {5.8.8} and AIX 7 {5.10.1}, soon to also be SLES of some level, not sure what level of Perl that will have). Much like many applications ship their own private JVM, really.

    I highly recommend considering that option.

[reply]

      I personally thought about it, but don't think $work will agree with me. We have dozens of servers, so just installing perl into /usr/local as AM suggested is not a solution, we have to build package to be able to manage dependencies. Then what to do with CPAN modules? Package every module separately -- a lot of work, build one big package with the perl and all CPAN modules -- then how to be with dependencies. I'm not saying that it is not possible to solve this problems, but it is quite a big (and what more important rather boring) task. And we are not just having this problem with perl, so if we're going this way it won't be Debian stable any more, so it makes more sense to just switch over to some other more dynamic distribution.

[reply]

      SLES of some level
      According to the openSUSE repos, SLES 11 uses 5.10.0. I'm not sure if that's entirely accurate, though.

      I advise doing this too. You can also use something like App::PerlBrew(although unfortunately that doesn't work for me for some reason), or just download your favourite Perl version from CPAN and compile that.
      I keep telling myself to use that, but I'd probably end up having to reinstall many of the modules(especially the XS ones), and that takes too much time.

      ~Thomas~
      confess( "I offer no guarantees on my code." );
[reply]
[d/l]

        For the record, I'm not using perlbrew for this. Instead, I've written a perl script (using the system perl) which will build perl and all 100+ modules from source tarballs, including some patch files for cases where the module just won't compile/test clean (usually on AIX). I've got my modules in three categories, though I'm about to merge two of them: dev, test, and modules. For the distribution that will ship, I'm not going to build dev or test, but if I want to ensure they all work on each platform I can at least throw in test temporarily just to be sure. Meanwhile, I'm expecting dev boxes to use all of them. If I'm not testing, I also have in that build-perl script code to rewrite Makefile.PL/Build.PL files to remove Test::* dependencies.

        The dev directory has things like Term::ReadLine::Perl (for making the perl debugger easier to use), PPI (for automated code manipulation), and Enbugger (and their prereqs not met in the modules directory). The test directory has a bunch of Test::*, but also HTTP::Daemon (for testing AnyEvent::HTTP, I think), Sub::Uplevel, and others.

        I can rebuild from scratch in ~10 minutes on my Linux box. It's a bit longer on AIX. Possibly because I do most of my building on Linux on an SSD drive :-)

[reply]
Re: Rediscovering fixed bugs
by Anonymous Monk on Oct 11, 2012 at 15:30 UTC
[reply]
Re: Rediscovering fixed bugs
by Anonymous Monk on Oct 11, 2012 at 23:11 UTC
    It's usually best to install your own more up-to-date Perl in a "/usr/local" directory and to use that for all the "real" things that you have to do ... just as you would do on a shared machine where you didn't have root-access. (Language versions in distro packages are usually quite old ... BUT they are the very ones that might be relied-upon by the package management software for that distro, so catch-22. This works around.)
[reply]

Back to Meditations