> -----Original Message-----
> From: Peter Prymmer [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 24, 2000 5:31 PM
> To: Craig A. Berry
> Cc: Jordan Henderson; [EMAIL PROTECTED]
> Subject: Re: testing Perl (was RE: VMS Perl bug (?) report)
>
>
>
>
> [big snip]
>
> > The poster of the original query in Nov. '98 says that his
> problem derived
> > from having no system identifiers defined:
> >
> >
> > <http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/1998-12/msg00013.html>
> >
> > I don't know if this was the case for the more recent problem. If so,
> > perhaps what we need is a panic test and abort after executing the loop in
> > vms_image_init() a few thousand times.
>
> You want to keep track of the number of times that vms_image_init()
> is called? What about implications for server damons such as mod_perl?
If I may speak for Craig, I think he was suggesting that there be a
counter set before the loop and incremented in the loop to see if this
loop has been executed some unreasonable number of times and aborting
when this is detected.
But, that doesn't seem to be a good suggestion. As we can see from
inspection and from the attached debugging that Anders Wallin performed,
the rlen/rsiz are never changed in the loop. This loop is clearly bogus,
so why bother counting the number of times it will loop invalidly? As
it stands, this code will always loop infinitely when (rlen < rsiz) is
true on entry (or abort from an eventual getjpi() status error).
This loop should be avoided, not aborted! Now, granted, there may be
a case that's being missed here (when all the identifiers weren't
gotten in the first pass), but this loop is no solution.
> Speaking of panic: the problem with t/lib/require.t is not unique to VMS
> and has cropped up on Solaris and elsewhere. Hence the fix ought to be a
> perl internals fix (which for all I know has already been posted.
>
> The successor to 5.6.0 is due out within a few weeks (less than a month).
> Peter Prymmer
-Jordan Henderson
-----
Message-ID: <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: Perl hangs on OpenVMS
Date: Mon, 3 Jul 2000 06:12:10 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Help: <mailto:[EMAIL PROTECTED]>
List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
Hi again !
Here is a follow up on the same piece of offending code, but on the GOOD
node. For some reason the variables rlen and rsz hold larger values, which
means that we don't go into that eternal (infernal) loop and we execute
normally.
The GOOD node is: AlphaServer 1000A 5/400, OpenVMS V7.1-2
The BAD node is: AlphaServer 1000A 5/400, OpenVMS V6.2-1H3
I have added the printf statements below.
THE CODE: (vms.c - vms_image_init)
===========================================
printf ("1 - rlen=%i, rsz=%i\n", rlen, rsz);
/* Rights identifiers might trigger tainting as well. */
if (!add_taint && (rlen || rsz)) {
printf ("2 - rlen=%i, rsz=%i\n", rlen, rsz);
while (rlen < rsz) {
/* We didn't get all the identifiers on the first pass.
Allocate a
* buffer much larger than $GETJPI wants (rsz is size in bytes
that
* were needed to hold all identifiers at time of last call;
we'll
* allocate that many unsigned long ints), and go back and get
'em.
*/
printf ("3 - rlen=%i, rsz=%i\n", rlen, rsz);
if (jpilist[1].bufadr != rlst) Safefree(jpilist[1].bufadr);
jpilist[1].bufadr = New(1320,mask,rsz,unsigned long int);
jpilist[1].buflen = rsz * sizeof(unsigned long int);
==========================================
The execution:
=====================================
$ MCR Sys$Disk:[]miniperl.exe "-I[.lib]" [.VMS]Writemain.pl
"DynaLoader Socket"
1 - rlen=312, rsz=312
2 - rlen=312, rsz=312
...
normal execution continues here
Regards
Anders Wallin
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, July 03, 2000 10:14 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Perl hangs on OpenVMS
>
> Found it !!!!
>
> I have located the offending code in the module VMS.C, specifically the
> routine vms_image_init. I include a piece of the code and a printout of
> the
> results.
>
> 1) The "printf" statement was added by me.
> 2) I applied the fix below, suggested by Craig A Berry. It seems not to
> have
> helped.
> --- vms.c;-1 Tue May 30 17:12:56 2000
> +++ vms.c Sun Jul 2 09:55:46 2000
> @@ -3852,7 +3852,7 @@
> */
> if (jpilist[1].bufadr != rlst) Safefree(jpilist[1].bufadr);
> jpilist[1].bufadr = New(1320,mask,rsz,unsigned long int);
> - jpilist[1].buflen = rsz * sizeof(unsigned long int);
> + rlen = jpilist[1].buflen = rsz * sizeof(unsigned long int);
>
> _ckvmssts(sys$getjpiw(0,NULL,NULL,&jpilist[1],iosb,NULL,NULL));
> _ckvmssts(iosb[0]);
>
>
> while (rlen < rsz) {
> /* We didn't get all the identifiers on the first pass. Allocate a
> * buffer much larger than $GETJPI wants (rsz is size in bytes that
> * were needed to hold all identifiers at time of last call; we'll
> * allocate that many unsigned long ints), and go back and get 'em.
> */
> printf ("rlen=%i, rsz=%i\n", rlen, rsz);
> if (jpilist[1].bufadr != rlst) Safefree(jpilist[1].bufadr);
> jpilist[1].bufadr = New(1320,mask,rsz,unsigned long int);
> rlen = jpilist[1].buflen = rsz * sizeof(unsigned long int);
> _ckvmssts(sys$getjpiw(0,NULL,NULL,&jpilist[1],iosb,NULL,NULL));
> _ckvmssts(iosb[0]);
> }
>
> PRINTOUT OF EXECUTION (never ending loop)
> rlen=40, rsz=184
> rlen=40, rsz=184
> rlen=40, rsz=184
> rlen=40, rsz=184
> rlen=40, rsz=184
> rlen=40, rsz=184.......
>
> Regards
>
> Anders Wallin
>
