This is not a Linux centric problem. I get the same thing on Windows XP
with ActiveState Perl 5.8.8.
I do not have an answer but I have some more clues.
I have sprinkled print statements about in PlClient.pm,
...\blib\lib\RPC\PlServer\Comm.pm, and
C:\perl\site\lib\Net\Daemon\Test.pm. The Comm.pm of PlClient just
routes to the Comm.pm of PlServer.
These three lines of PlClient.pm are where the problms eventually show up.
$comm->Write($socket, [$app, $version, $user, $password]);
$self->Debug("Waiting for server's response ...");
my $reply = $comm->Read($socket);
My prints show that ref($socket), ref($client) and other variables all
have valid ref names or values. This seems to be true in the callers
and in the invoked subroutines. Hence, no problems in that area.
BTW: The PlClient Comm.pm just routes to the PlServer Comm.pm code.
In Comm.pm, sub Read, I print the results of
my $result = $socket->read($encodedSize, $readSize,
length($encodedSize));
When $result is 0, this line of Comm.pm gest executed:
return undef if defined($result);
and so undef is returned to the PlClient line
my $reply = $comm->Read($socket);
which makes $reply to be undef.
PlClient gives back the undef to its caller in lib.pl, in the line below.
Test($client = eval { RPC::PlClient->new(@_) })
or print "Failed to make second connection: $@\n";
which results in the "Use of uninitialized value ..." from lib.pl when
an attemp is made to use $client.
I printed out the peerport and other vars. peerport gets numbers such
as 3900, 4157 and so on. There is no consistency of peerport when this
fails. The only consistency is that for the tests that pass, the above
mentioned $result is 4. When it fails, Read's $result is always showing 0.
Could there be underlying C code that is allowing a port to be assigned
that is already in use?
My level of expertise has been reached. If any one has any "try this or
that" ideas, I would welcome them.
Thanks
