At 2:58 PM +0200 8/15/02, [EMAIL PROTECTED] wrote:
>Content-Type: text/html;
There are folks who read this list with text-only mailers.
>We are upgrading our systems from VMS 7.2-1 to VMS 7.3-1, as well as from an in-house
>build of Perl 5.005_03 to the Compaq Perl 5.6.1 binary distribution.
>
>For some reason one (and only one) of our scripts is causing an ACCVIO in the perl
>interpreter.
This is new after the upgrade? Do you get a stack dump or
"improperly handled condition, image exit forced"?
>I have isolated it to a single line, which is a call to "close ($fh)", where "$fh" is
>a file handle which has been bound to a socket. The crash is very intermittent, and
>I cannot reproduce it with a simple test program. However, the code roughly does
>something like this:
>
>#####################################################################
>use Filehandle;
>use Socket qw( SOCK_STREAM PF_INET inet_aton sockaddr_in inet_ntoa INADDR_ANY);
>
>$handle = FileHandle->new();
>socket($handle, &PF_INET(), &SOCK_STREAM(), getprotobyname('tcp'));
>bind($handle, sockaddr_in(0, INADDR_ANY)) || die "Could not bind\n";
>$saddr = sockaddr_in(1984, inet_aton("op1t301gwy.opf.swissbank.com"));
>
>$connected = 0;
>
># Use an alarm inside "eval" to avoid blocking.
>eval {
> $SIG{'ALRM'} = sub { die "Timed out" };
> alarm(1);
>
> if(connect($handle, $saddr) ) {
> $connected = 1;
> }
> alarm(0);
> };
> alarm(0);
>
> if (! $connected) {
>
> print "Connect failed!\n";
> close $handle; # ACCVIO happens right here!
>
>} else {
> print "Connected successfully!\n";
> select( undef, undef, undef, 0.5 );
> close( $handle );
> select( undef, undef, undef, 0.1 );
>}
>#####################################################################
>
>Does anyone see anything horribly wrong or dangerous with this? To be precise, the
>code which is actually failing is a perl module which does (roughly) the above, and
>it has 1 file handle per instantiation, allocated in the constructor. The failure
>seems to occur only when the connection times out and it hits the "close $handle;"
>statement -- but not consistenty.
Is it possible alarm(0) doesn't really do its thing inside an eval?
You may want to look at the worrisome comments about how unsafe
signal handlers are at:
<http://www.perldoc.com/perl5.8.0/pod/perlipc.html#Deferred-Signals>
Another thing to try is the Time::HiRes extension, which has a
drop-in replacement for the alarm() function and is based on
ualarm(). There's a chance it's more reentrant.
All wild guesses. I'm afraid I don't really know what's going on here.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
