Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#4 memory leak using vaffines

critical
closed
core (120)
5
2000-05-07
2000-04-01
No

memory is leaked when vaffines which have been made physical are destroyed

Some of the relevant emails:

Ok, so here are the results of my tests so far:

1)

$a = zeroes(100); while (1) { $a->dummy(0) }

leaks due to the mentioned perl bug

2)

$a = zeroes(100); while (1) { $a->any_vaffine_trans }

does not leak (any_vaffine_trans = xchg, slice, etc)

3) but

$a = zeroes(100); while (1) { $a->any_vaffine_trans->make_physvaffine
}

does. So somewhere between making the trans physical and destruction
something is not freed.

---
Tuomas J. Lukka wrote:
> And 3 is surely not due to 1?

Don't think so.

>
> Is the leakage dependent on the size of $a or the resulting piddle?

Doesn't seem to be the case.

> Is the leakage dependent on the number of dimensions in $a or the resulting piddle?
> (use piddles with 100 dimensions to find out).

Yup, seemed to scale with no of dims.

>
> What about if you store the result and change the order in which they
> are destroyed?

No difference.

Also, a $a->vaffineXXX->make_physdims is sufficient to cause the
problem.

----

> sub testfunc {
> $_[1] = 1 if ($#_ < 1);
> }
>
> while(1)
> {
> testfunc(0);
> $i++;
> print "$i\n" if $i % 500 == 0;
> }
>
> Should one consider this as a perl bug?

Definitely. Incredible.

This explains part of the dummy problem

Discussion

  • fixed in latest cvs
    involved changing a rule in PP.pm that was not correctly called due to name clash

     
    • assigned_to: nobody --> csopen
    • status: Error - status not found --> closed