memory leak in Symbol.pm

[p5pRT]

Migrated from rt.perl.org#3294 (status was 'resolved')

Searchable as RT3294$

[p5pRT]

From spiff@phreax.net

Hi Perlbug Team,

while fiddling with Symbol.pm's delete_package i noticed
that it clears the symbol table of the package in question,
but does not free the stuff the symbols points to. When
reloading and deleting a package over and over again, perl's
mem usage grows with apparently no limit.

I tested this behaviour with perl 5.005 and 5.6.0 on linux.
The bug can be fixed using a combination of the code from
Symbol.pm and the code mentioned in the FAQ (perlfaq7, how to
clear a package). The code from the FAQ alone doesn't do the
job either, as it clears the symbols, but leaves the symbol
table in place.

With the attached patch applied to Symbol.pm, mem usage stays
constant, even when loading symbols into packages with unique
names. The attached test.pl performs this test.

Besides patching Symbol.pm, i suggest removing the code snippet
from the FAQ in favour of the reference to Symbol​::delete_package.

Regards,
  Karsten Sperling

[p5pRT]

From spiff@phreax.net

symbol.diff

[p5pRT]

From spiff@phreax.net

test.pl

[p5pRT]

From [Unknown Contact. See original ticket]

This is a message in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--AKMAILBOUNDARY
Content-Type​: text/plain; charset=us-ascii
Content-Transfer-Encoding​: 7bit

Hi Perlbug Team,

while fiddling with Symbol.pm's delete_package i noticed
that it clears the symbol table of the package in question,
but does not free the stuff the symbols points to. When
reloading and deleting a package over and over again, perl's
mem usage grows with apparently no limit.

I tested this behaviour with perl 5.005 and 5.6.0 on linux.
The bug can be fixed using a combination of the code from
Symbol.pm and the code mentioned in the FAQ (perlfaq7, how to
clear a package). The code from the FAQ alone doesn't do the
job either, as it clears the symbols, but leaves the symbol
table in place.

With the attached patch applied to Symbol.pm, mem usage stays
constant, even when loading symbols into packages with unique
names. The attached test.pl performs this test.

Besides patching Symbol.pm, i suggest removing the code snippet
from the FAQ in favour of the reference to Symbol​::delete_package.

Regards,
  Karsten Sperling

--AKMAILBOUNDARY
Content-Type​: application/octet-stream; name="symbol.diff"
Content-Transfer-Encoding​: base64

LS0tIC91c3IvbGliL3Blcmw1LzUuNi4wL1N5bWJvbC5wbQlTdW4gTWF5IDI4
IDE0OjAyOjIwIDIwMDAKKysrIFN5bWJvbC5wbQlTdW4gTWF5IDI4IDE0OjU4
OjA1IDIwMDAKQEAgLTEyOSw4ICsxMjksMjEgQEAKICAgICBteSAkc3RlbV9z
eW10YWIgPSAqeyRzdGVtfXtIQVNIfTsKICAgICByZXR1cm4gdW5sZXNzIGRl
ZmluZWQgJHN0ZW1fc3ltdGFiIGFuZCBleGlzdHMgJHN0ZW1fc3ltdGFiLT57
JGxlYWZ9OwogCi0gICAgbXkgJGxlYWZfZ2xvYiAgID0gJHN0ZW1fc3ltdGFi
LT57JGxlYWZ9OwotICAgIG15ICRsZWFmX3N5bXRhYiA9ICp7JGxlYWZfZ2xv
Yn17SEFTSH07CisKKyAgICAjIGZyZWUgYWxsIHRoZSBzeW1ib2xzIGluIHRo
ZSBwYWNrYWdlCisKKyAgICBteSAkbGVhZl9zeW10YWIgPSAqeyRzdGVtX3N5
bXRhYi0+eyRsZWFmfX17SEFTSH07CisgICAgZm9yZWFjaCBteSAkbmFtZSAo
a2V5cyAlJGxlYWZfc3ltdGFiKSB7CisgICAgICAgIG15ICRmdWxsbmFtZSA9
ICRwa2cgLiAkbmFtZTsKKyAgICAgICAgdW5kZWYgJCRmdWxsbmFtZTsKKyAg
ICAgICAgdW5kZWYgQCRmdWxsbmFtZTsKKyAgICAgICAgdW5kZWYgJSRmdWxs
bmFtZTsKKyAgICAgICAgdW5kZWYgJiRmdWxsbmFtZTsKKyAgICAgICAgdW5k
ZWYgKiRmdWxsbmFtZTsKKyAgICB9CisKKworICAgICMgZGVsZXRlIHRoZSBz
eW1ib2wgdGFibGUKIAogICAgICUkbGVhZl9zeW10YWIgPSAoKTsKICAgICBk
ZWxldGUgJHN0ZW1fc3ltdGFiLT57JGxlYWZ9Owo=
--AKMAILBOUNDARY
Content-Type​: application/octet-stream; name="test.pl"
Content-Transfer-Encoding​: base64

dXNlIFN5bWJvbCBxdyhkZWxldGVfcGFja2FnZSk7CgokY29kZSA9ICcKCSMg
c29tZSBzeW1ib2xzIHdpdGggc29tZSBkYXRhIGF0dGFjaGVkIHRvIHRoZW0K
CXN1YiBmb28geyBwcmludCgiZm9vb29vb29vb29vb29vb28iKSB9CgkkYmFy
ID0gImFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWEiIC4KCSJhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYSIgLgoJImFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhIiAuCgkiYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWEiIC4KCSJh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYSIgLgoJImFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhIiAuCgki
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWEiIC4KCSJhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYSIgLgoJ
ImFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhIiAuCgkiYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWEiIC4K
CSJhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYSIgLgoJImFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhIjsK
CXByaW50KCJsb2FkZWQgIiAuIF9fUEFDS0FHRV9fIC4gIlxuIik7IAoJMTsK
JzsKCiRjbnQgPSAwOwp3aGlsZSAoMSkgewoJJGNudCsrOwoJJHBrZyA9ICJG
b286OlBrZyR7Y250fSI7CglwcmludCgiJHBrZyBzYXlzOiAiKTsKCWV2YWwo
InBhY2thZ2UgJHtwa2d9OyAke2NvZGV9Iikgb3IgZGllKCIkQCIpOwoJZGVs
ZXRlX3BhY2thZ2UoJHBrZyk7Cn0KCgo=
--AKMAILBOUNDARY--

[p5pRT]

From p5p@spam.wizbit.be

I can reproduce the memory leak in perl-5.8.8 but not in perl-5.10.0.

(Also saw this memory leak in another bug report.)

[p5pRT]

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'