in reply to Re: Non-deterministic behaviour with simple array initialization
in thread Non-deterministic behaviour with simple array initialization

Hi,

thanks for the suggestion. I wrote a TestFor package, pretty straight according to the documentation, as seen below. The problem persists, and besides TIEARRAY and DESTROY once and many times FETCHSIZE, there is no method called on @e.

To clarify:

The program is changed to:

#!/usr/bin/perl use strict; use warnings; use TestFor; my @e; // moved outside as suggested before tie @e, 'TestFor', 0; my $i = 0; BIGLOOP: while (1) { # my @e; for my $j (0..@e / 2 - 1) { print "died where I shouldn't have: $i\n"; last BIGLOOP; } $i++; }

The file TestFor.pm:

package TestFor; use Carp; sub TIEARRAY { my $class = shift; my $elemsize = shift; if ( @_ || $elemsize =~ /\D/ ) { croak "usage: tie ARRAY, '" . __PACKAGE__ . "', elem_size"; } print "TIEARRAY\n"; return bless { ELEMSIZE => $elemsize, ARRAY => [], }, $class; } sub FETCH { my $self = shift; my $index = shift; print "FETCH\n"; return $self->{ARRAY}->[$index]; } sub STORE { my $self = shift; my ( $index, $value ) = @_; if ( length $value > $self->{ELEMSIZE} ) { croak "length of $value is greater than $self->{ELEMSIZE}"; } # fill in the blanks $self->EXTEND($index) if $index > $self->FETCHSIZE(); # right justify to keep element size for smaller elements $self->{ARRAY}->[$index] = sprintf "%$self->{ELEMSIZE}s", $value; print "STORE\n"; } sub FETCHSIZE { my $self = shift; #print "FETCHSIZE\n"; // was called very often return scalar @{ $self->{ARRAY} }; } sub STORESIZE { my $self = shift; my $count = shift; if ( $count > $self->FETCHSIZE() ) { foreach ( $count - $self->FETCHSIZE() .. $count ) { $self->STORE( $_, '' ); } } elsif ( $count < $self->FETCHSIZE() ) { foreach ( 0 .. $self->FETCHSIZE() - $count - 2 ) { $self->POP(); } } print "STORESIZE\n"; } sub DESTROY { print "DESTROY\n"; } 1;
Still, same problem.

Replies are listed 'Best First'.
Re^3: Non-deterministic behaviour with simple array initialization
by BrowserUk (Patriarch) on Sep 25, 2008 at 23:53 UTC

    The only other suggestion I have (which at least won't involve so much work!), is to see if you get the same problem if the array is a global: our @e.

    Beyond that, it sounds like you just have a broken build. Rebuild it, or if its a vendor build grab an ealier one and report the problem to whomever built it.

    Even if you tracked down what caused it, what would you do about it?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Yes, I do, no change with 'our @e'.

      I'm going now for steamroller tactics ... I reinstall all the distribution packages in order to avoid corrupted data.

      What I would do about it? Well, that would strongly depend on the cause, once I knew it ... :)