Problems with fork or socket code???

mortenal has asked for the wisdom of the Perl Monks concerning the following question:

Under win32 ActivePerl, I'm using the following code, and when i make a connection to port 8009 it works fine, but when i make connections to port 8008, right when i try to connect a second time, the program crashes. code:
$serverA (8008) is the one that forks, and the one that crashes. $serverL (8009) works fine.
Oddly enough, the program crashes on the line with three stars before it.

use IO::Socket;
use IO::Select;

#require 'c:\perl\banner.pl';

sub spawn; #forward declaration

# Create a socket to listen on.
#
my $serverA = #handles ad requests
  IO::Socket::INET->new( LocalPort => 8008, Listen => 5, Reuse => 1 );
my $serverL = #handles log requests
  IO::Socket::INET->new( LocalPort => 8009, Listen => 5, Reuse => 1 );

die "Can't create socket for listening: $!" unless $serverA;
print "Listening for connections on port 8008\n";
die "Can't create socket for listening: $!" unless $serverL;
print "Listening for connections on port 8009\n";


my $readable = IO::Select->new;     # Create a new IO::Select object
$readable->add($serverA);           # Add the servers to it
$readable->add($serverL);

while(1) {

    # Get a list of sockets that are ready to talk to us.
    #
    my ($ready) = IO::Select->select($readable, undef, undef, undef);
#***
    foreach my $s (@$ready) {
        # Is it a new connection?
        #
        if($s == $serverL) {
        
            # Grab the request, close the socket, and log it as fast as we can
            #
            my $new_sock = $serverL->accept;
            my $in=<$new_sock>;
            $new_sock->close;
#            slog($in);
            print $in;

            
        } elsif($s == $serverA) {
            # Fork off, get the request, and reply with the banner
            #
            my $new_sock = $serverA->accept;
            spawn $new_sock;

            
        } else {  # It's an established connection, and shouldn't be here
            $s->close;
        }
    }
}

sub spawn {
    my $client=shift;
    my $pid;

    if (!defined($pid = fork)) {
        die "can't fork";
        return;
    } elsif ($pid) {
        return; # I'm the parent
    }
    $in=<$client>; #get the request
#    print $client &process_request($in);
    print $client $in;
    $client->close;
    exit;
}

Thanks, --tom

Comment on Problems with fork or socket code???

Replies are listed 'Best First'.
Re: Problems with fork or socket code??? by tye (Sage) on Aug 27, 2000 at 08:58 UTC
the program crashes That is always a lousy description of what happened. Does it give you an error message? Taking a guess, did it complain about not being able to use "undef" as an array reference? `my ($ready) = IO::Select->select($readable, undef, undef, undef); foreach my $s (@$ready) {` [download] If you read the documentation for IO::Select->select(), you will see that it returns either a list of three references to arrays or an empty list. In the later case, $ready will end up `undef`. I'm guessing you have a `use strict` that you didn't show us and trying to do @$ready on `undef` kills your script. What you should do is something like: `my ($ready) = IO::Select->select($readable, undef, undef, undef); die "IO::Select->select() failed: $!\n" unless $ready; foreach my $s (@$ready) {` [download] The $! bit will tell you why the select call failed. Once you have that, you or someone here will probably be able to figure out why it is failing or at least what to try next. If I didn't guess right, then give us more information and we'll probably be able to help. I suspect the problem stems from the child using a file handle (or a Win32 socket in particular) opened by the parent. I haven't investigated the details of the fork() emulation that ActivePerl now has. So I'm not sure how many Unixisms are properly emulated by it. I'm not sure what caveats there are when structures are copied to the new interpretter that is built in the new thread, especially when it comes to file handles and sockets. - tye (but my friends call me "Tye")	[reply] [d/l] [select]
RE: Re: Problems with fork or socket code??? by mortenal (Novice) on Aug 27, 2000 at 11:38 UTC
Nope, no strict... If it did anything more than just crash, I would have put up the error message. Perl doesn't give an error message. Windows just spits out a 'fatal exception' or somesuch message (away from that box right now, or i'd say what it was), and the program dies, all open connections are closed. The only info I was able to get was where it crashed (by inserting on every line 'print (line_number);'). i hadn't thought of that ($!), but i'll try it out as soon as i get back to the box. Thanks, --tom	[reply]
RE: Re: Problems with fork or socket code??? by mortenal (Novice) on Aug 27, 2000 at 22:02 UTC
Windows says that Perl performed an illegal operation (invalid page fault in perl56.dll)... I put the code you suggested in, and it passes it without a problem... Thanks, --tom	[reply]
Re: Problems with fork or socket code??? by tye (Sage) on Aug 28, 2000 at 00:46 UTC
If it did anything more than just crash, I would have put up the error message. Windows says that Perl performed an illegal operation (invalid page fault in perl56.dll)... No, you didn't give the error message until now. And "crash" doesn't imply that the operating system popped up a window. An invalid page fault is basically a bug in Perl. It would be good to report this using the perlbug script. Your script that produces the problem is already pretty small. What is missing so that the bug fixers can reproduce the problem is a small script that sends packets to those sockets in a way that triggers the fault. The pseudo fork() in ActivePerl is quite new and so finding bugs with it is to be expected. - tye (but my friends call me "Tye")	[reply]
And the solution is... by mortenal (Novice) on Aug 28, 2000 at 01:33 UTC
Don't use windows! fork() doesn't work right under ActivePerl... program works perfectly under Linux... well, having trouble reaping my kids, but that shouldn't take too long to figure out. --tom	[reply]