Mailing List Archive: Further to: panic: pad_sv po at test1.pl line 58075.

Further to: panic: pad_sv po at test1.pl line 58075.

Oct 10, 1995, 5:43 PM

Post #1 of 6 (1073 views)

Hi

A problem I reported earlier "panic: pad_sv po at test1.pl line 58075"
went away when I installed perl5.001m (blush).

However it returned in a different guise. The problems appears to be
that when reading a long ARRAY (or HASH), the 65535th string in the
ARRAY overwrites the values return by undef !

I have a written a short script (showbug.pl) which writes another a
long script (bug.pl) which demonstrates the error. bug.pl is 644K and
running the script uses a lot of memory so you may not be able to
reproduce the error.

I'm afraid, I can't tell why the problems has occurred.

It seems to go away if the element of the array use ' not ".

Robin Barker

$ cat showbug.pl
use strict;

my $file = 'bug.pl';
open BUG, "> $file" or die "open $file: $!\n";

print BUG "use strict;";
print BUG "print undef if [.";

for (1..shift) { print BUG "\"K$_\"," }

print BUG "];";

close BUG or die "close $file\n";

do $file;

$ perl -v

This is perl, version 5.001

Unofficial patchlevel 1m.

Copyright 1987-1994, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
$ perl -lw showbug.pl 4 # a small example
Use of uninitialized value at bug.pl line 2.

$ cat bug.pl # just to see what bug.pl looks like
use strict;
print undef if [
"K1",
"K2",
"K3",
"K4",
];
$ perl -lw showbug.pl 65534 # this takes a while
Use of uninitialized value.

$ perl -lw bug.pl # lets just check that
Use of uninitialized value.

$ perl -lw showbug.pl 65535 # but what about this !
K65535
$ perl -lw bug.pl # lets just see that again !!
K65535

_________________________________________________________________
Robin Barker, | Email: rmb@ditc.npl.co.uk
Open Sytems Group, | Tel: +44 (0)181 943 7090
CISE, National Physical Laboratory, | Fax: +44 (0)181 977 7091
Teddington, Middlesex, UK. TW11 0LW | WWW: http://www.ess.npl.co.uk/

Re: Further to: panic: pad_sv po at test1.pl line 58075. [ In reply to ]

Oct 10, 1995, 10:15 AM

Post #2 of 6 (1042 views)

Robin Barker writes:
>
> Hi
>
> A problem I reported earlier "panic: pad_sv po at test1.pl line 58075"
> went away when I installed perl5.001m (blush).
>
> However it returned in a different guise. The problems appears to be
> that when reading a long ARRAY (or HASH), the 65535th string in the
> ARRAY overwrites the values return by undef !
>
> I have a written a short script (showbug.pl) which writes another a
> long script (bug.pl) which demonstrates the error. bug.pl is 644K and
> running the script uses a lot of memory so you may not be able to
> reproduce the error.
>
> I'm afraid, I can't tell why the problems has occurred.
>
> It seems to go away if the element of the array use ' not ".

This may be related to what I send out in March (still here in
5.001m+):

perl -lwe '$#a=0;for(@a){print 1;$_->[1]+=4;print undef}'
1
Use of uninitialized value at -e line 1.
ARRAY(0x19d928)

The reason was that sv_undef was _upgradable_.

Ilya

Re: Further to: panic: pad_sv po at test1.pl line 58075. [ In reply to ]

lwall at scalpel

Oct 10, 1995, 10:35 AM

Post #3 of 6 (1044 views)

I've reproduced it here. Great test case! Thanks.

Larry

Re: Further to: panic: pad_sv po at test1.pl line 58075. [ In reply to ]

Oct 10, 1995, 11:53 AM

Post #4 of 6 (1046 views)

On Tue, 10 Oct 1995 10:35:36 PDT, Larry Wall wrote:
>I've reproduced it here. Great test case! Thanks.
>
>Larry
>

Hmm, PADOFFSET is a U16, any reason it can't be a U32?
This eliminates the problem (well not really, but at least
pushes the ante much higher).

- Sarathy.
gsar@engin.umich.edu

Re: Further to: panic: pad_sv po at test1.pl line 58075. [ In reply to ]

lwall at scalpel

Oct 10, 1995, 12:29 PM

Post #5 of 6 (1048 views)

: On Tue, 10 Oct 1995 10:35:36 PDT, Larry Wall wrote:
: >I've reproduced it here. Great test case! Thanks.
: >
: >Larry
: >
:
: Hmm, PADOFFSET is a U16, any reason it can't be a U32?
: This eliminates the problem (well not really, but at least
: pushes the ante much higher).

That's part of the fix. The other part is to tell the lexer it doesn't
have to stringify double-quoted strings that don't do any
interpolation. OP_STRINGIFY is allocated a temp location in the pad,
even though the opcode is later optimized away. And the test case runs
about 3 times faster when I do this.

Larry

Re: Further to: panic: pad_sv po at test1.pl line 58075. [ In reply to ]

Oct 10, 1995, 12:59 PM

Post #6 of 6 (1045 views)

On Tue, 10 Oct 1995 12:29:07 PDT, Larry Wall wrote:
>:
>: Hmm, PADOFFSET is a U16, any reason it can't be a U32?
>: This eliminates the problem (well not really, but at least
>: pushes the ante much higher).
>
>That's part of the fix. The other part is to tell the lexer it doesn't
>have to stringify double-quoted strings that don't do any
>interpolation. OP_STRINGIFY is allocated a temp location in the pad,
>even though the opcode is later optimized away. And the test case runs
>about 3 times faster when I do this.

Cool indeed. Watch it mawk people, we're closing in fast.. :-)

- Sarathy.
gsar@engin.umich.edu