Skip Menu |

This queue is for tickets about the Crypt-SSLeay CPAN distribution.

Report information
The Basics
Id: 12444
Status: resolved
Priority: 2/
Queue: Crypt-SSLeay

People
Owner: dland [...] cpan.org
Requestors: jamesb [...] decideinteractive.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.49
Fixed in: (no value)



Subject: Alarm Clock errors
Hello, Every now & again one of our perl jobs crashes with a SIGALRM, which is reported as "Alarm Clock" by the calling shell script. This only happens when downloading a https URL using the LWP library. Happens very rarely, a dozen or so occasions in a year or so of running 100 jobs a day, but or more recently now thatour system is under much higher stress. Have a theory that the problem is in in Net::SSL::connect. (and maybe similar problem in Net::SSL::read) The theory is that in the connect subroutine in SSL.pm it is using 'local $SIG{ALRM}' which sets the signal handler for the scope of the eval. At the end of the block is the alarm(0) to disable the alarm. Now if I understand all the signal stuff right (unlikely) then if something dies within that scope then it would jump to the end of the eval, and the signal handler would no longer be used, but the alarm is still ticking? So would it be better to have something more of the structure? local $SIG{ALRM} = sub { $self->die_with_error("SSL read timeout") }; eval { alaram(timeout) .... }; alarm(0); ... That way we are sure the alarm is being switched off, even if we fail? Don't know if I'm talking crap or not, I'm not much of a network programmer and have no concept of the big picture. Simply narrowed down to here by grepping for calls to 'alarm' in the lib/perl tree on our server. Let me know if I can do anything to help. Have fun, James Distribution Crypt-SSLeay-0.49 (Containing Net::SSL 2.77) uname -a Linux Batn04 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 i686 i386 GNU/Linux perl -V Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Platform: osname=linux, osvers=2.4.21-9.elsmp, archname=i386-linux-thread-multi uname='linux bugs.devel.redhat.com 2.4.21-9.elsmp #1 smp thu jan 8 17:08:56 est 2004 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dversion=5.8.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.2 5.8.1 5.8.0' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -g -pipe -march=i386 -mcpu=i686', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.3.2 20031218 (Red Hat Linux 3.3.2-5)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Feb 25 2004 13:30:53 @INC: /usr/lib/perl5/5.8.3/i386-linux-thread-multi /usr/lib/perl5/5.8.3 /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl
RT-Send-CC: jamesb [...] decideinteractive.com
On Thu Apr 28 02:58:49 2005, guest wrote: Show quoted text
> Hello, > Every now & again one of our perl jobs crashes with a SIGALRM, which > is reported as "Alarm Clock" by the calling shell script. This > only happens when downloading a https URL using the LWP library. > Happens very rarely, a dozen or so occasions in a year or so of > running 100 jobs a day, but or more recently now thatour system is > under much higher stress.
Hello, I am the new maintainer for Crypt-SSLeay. Could you please try with the latest development version? This is available as D/DL/DLAND/Crypt-SSLeay-0.52_01.tar.gz This distribution is identical to 0.51 except for a one-line change to initialise the SSL library. Let me know if this resovles the problem. Your problem seems a little different to the other open tickets. If you're still interested in clearing this up let me know. Thanks, David
From: jeff at zeroclue dot com
On Wed Dec 20 13:30:24 2006, DLAND wrote: Show quoted text
> I am the new maintainer for Crypt-SSLeay. Could you please try with the > latest development version? This is available as > > D/DL/DLAND/Crypt-SSLeay-0.52_01.tar.gz
Hi, I'm using version 0.53 of Crypt::SSLeay and I believe this bug is still present. It looks like the problem is the order of lines 229 and 240 in Net/SSL.pm. If the read fails, the alarm is not cancelled, and the subroutine is exited leaving no SIG{ ALRM } handler in place. I believe the attached patch to SSL.pm should fix the problem.
--- /Library/Perl/5.8.6/darwin-thread-multi-2level/Net/SSL.pm 2006-12-26 09:12:15.000000000 -0800 +++ SSL.pm 2007-01-24 07:44:29.000000000 -0800 @@ -226,8 +226,8 @@ alarm_ok() && alarm($self->timeout); my $n=*$self->{'ssl_ssl'}->read(@_); - $self->die_with_error("read failed") if !defined $n; alarm_ok() && alarm(0); + $self->die_with_error("read failed") if !defined $n; $n; }
From: dland [...] cpan.org
On Wed Jan 24 10:53:37 2007, JLAVALLEE wrote: Show quoted text
> On Wed Dec 20 13:30:24 2006, DLAND wrote:
> > I am the new maintainer for Crypt-SSLeay. Could you please try with the > > latest development version? This is available as > > > > D/DL/DLAND/Crypt-SSLeay-0.52_01.tar.gz
> > Hi, I'm using version 0.53 of Crypt::SSLeay and I believe this bug is > still present. It looks like the problem is the order of lines 229 and > 240 in Net/SSL.pm. If the read fails, the alarm is not cancelled, and > the subroutine is exited leaving no SIG{ ALRM } handler in place. I > believe the attached patch to SSL.pm should fix the problem.
Hi Jeff, yes, that makes sense. I'll roll out a development version with this patch in. Look for 0.53_01 soon. Thanks, David
From: dland [...] cpan.org
On Wed Jan 24 10:53:37 2007, JLAVALLEE wrote: Show quoted text
> On Wed Dec 20 13:30:24 2006, DLAND wrote:
> > I am the new maintainer for Crypt-SSLeay. Could you please try with the > > latest development version? This is available as > > > > D/DL/DLAND/Crypt-SSLeay-0.52_01.tar.gz
> > Hi, I'm using version 0.53 of Crypt::SSLeay and I believe this bug is > still present. It looks like the problem is the order of lines 229 and > 240 in Net/SSL.pm. If the read fails, the alarm is not cancelled, and > the subroutine is exited leaving no SIG{ ALRM } handler in place. I > believe the attached patch to SSL.pm should fix the problem.
Yes, that makes sense. I've applied this patch and uploaded a development release. Look for 0.53_01 coming to a mirror near you. If no-one complains bitterly about it, I'll put out 0.54 in a week or so. Thanks, David
On Wed Jan 24 10:53:37 2007, JLAVALLEE wrote: Show quoted text
> On Wed Dec 20 13:30:24 2006, DLAND wrote:
> > I am the new maintainer for Crypt-SSLeay. Could you please try with the > > latest development version? This is available as > > > > D/DL/DLAND/Crypt-SSLeay-0.52_01.tar.gz
> > Hi, I'm using version 0.53 of Crypt::SSLeay and I believe this bug is > still present. It looks like the problem is the order of lines 229 and > 240 in Net/SSL.pm. If the read fails, the alarm is not cancelled, and > the subroutine is exited leaving no SIG{ ALRM } handler in place. I > believe the attached patch to SSL.pm should fix the problem.
Hi Jeff, can you take 0.54 for a spin and see if it has fixed up your alarm bug? Thanks, David
On Sun Apr 15 18:11:13 2007, DLAND wrote: Show quoted text
> On Wed Jan 24 10:53:37 2007, JLAVALLEE wrote:
> > On Wed Dec 20 13:30:24 2006, DLAND wrote:
> > > I am the new maintainer for Crypt-SSLeay. Could you please try
with the Show quoted text
> > > latest development version? This is available as > > > > > > D/DL/DLAND/Crypt-SSLeay-0.52_01.tar.gz
> > > > Hi, I'm using version 0.53 of Crypt::SSLeay and I believe this bug is > > still present. It looks like the problem is the order of lines 229 and > > 240 in Net/SSL.pm. If the read fails, the alarm is not cancelled, and > > the subroutine is exited leaving no SIG{ ALRM } handler in place. I > > believe the attached patch to SSL.pm should fix the problem.
> > Hi Jeff, > > can you take 0.54 for a spin and see if it has fixed up your alarm bug?
Jeff, have you been able to see whether your problem is fixed? Thanks, David
Not having heard anything one way or another about this bug, I am marking it resolved. Thanks for the report, David