Craig:
Hi. I had my mail format default set to HTML instead of text -- sorry!
This crash problem is new, since our upgrade.
Old environment:
Alpha OpenVMS 7.2-1, TCP/IP Services v5.0A ECO3, Perl 5.005_03 built in-house from
CPAN source
New environment:
Alpha OpenVMS 7.3-1, TCP/IP Services v5.1 ECO 4, Perl 5.6.1 binary distribution
downloaded from Compaq.
The exact error we get is:
%SYSTEM-F-ACCVIO, access violation, reason mask=04,
virtual address=7AE196E000000009, PC=FFFFFFFF80A376A4, PS=0000001B
Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
7AE196E000000009
FFFFFFFF80A376A4
000000000000001B
Now, I have a more general question: This code is setting an ALRM callback and an
"alarm()" timer inside an eval {} block, in order to avoid blocking indefinitely on
the "connect()" call.
But when could it ever block indefinitely on connect()? I thought connect() just
returned TRUE or FALSE but never blocked... is that not the case? Can anyone think of
a situation where "connect()" could possibly block forever?
The code in question is a BigSister client, so even if it does block, it doesn't
really matter, since if the BigSister server is down, the client might just as well be
blocked, since it's only job is to report status information back to the BigSister
server.
Regards,
David Hansen
UBS Warburg Switzerland
-----Original Message-----
From: Craig A. Berry [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 16, 2002 7:27 AM
To: Hansen, David
Cc: [EMAIL PROTECTED]
Subject: Re: Compaq Perl 5.6.1 crashing in "close()"
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
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
