develooper Front page | perl.perl5.porters | Postings from October 2003

RE: Fixed: [perl #24255] shared hash ref memory leak in 5.8.1

From:
Jack Steadman
Date:
October 25, 2003 14:16
Subject:
RE: Fixed: [perl #24255] shared hash ref memory leak in 5.8.1
Message ID:
DKENINFNLHPJPCELKLPAEEGMCJAA.perlbug@wallofcuriosities.com

i've got another reproducible case for you.  the following code, running on
5.8.1 with the leak patch installed, still leaks memory:

#!/usr/bin/perl

use strict;
use threads;
use threads::shared;
use Thread::Queue;

my $top = &share({});
$top->{mid} = &share({});

my $i = 0;
my $state = 1;
while (1) {

	## any array/hash/object reference
	my $queue = new Thread::Queue;

	if ($state) {
		print "adding key $i\n";
		$top->{mid}->{$i} = $queue;
	} else {
		print "deleting key $i (sort of)\n";
		$top->{mid}->{$i} = undef;
	}

	$i++;
	if ($i > 10) {
		$i = 0;
		$state = ($state) ? 0 : 1;
	}
}

as i said earlier (and elizabeth verified), deleting the hash key with a
'delete $top->{mid}->{$i};' causes a seg fault, so i've tried setting them
to undef to at least get the object assigned to the key to be destroyed.
however, it seems that setting the key to a scalar or undef causes the
object *not* to be destroyed.  the following code, which is essentially the
code i sent in my original bug report, does not leak (as it shouldn't with
the patch installed):

#!/usr/bin/perl

use strict;
use threads;
use threads::shared;
use Thread::Queue;

my $top = &share({});
$top->{mid} = &share({});

my $i = 0;
my $state = 1;
while (1) {

	## any array/hash/object reference
	my $queue = new Thread::Queue;

	if ($state) {
		print "adding key $i\n";
		$top->{mid}->{$i} = $queue;
	}
	## only difference from above - else clause removed

	$i++;
	if ($i > 10) {
		$i = 0;
		$state = ($state) ? 0 : 1;
	}
}

without the explicit setting of the hash key to undef or a scalar (i tried
setting to zero also), the object seems to be freed.  setting a hash key
that contains an object ref to another object ref seems to have the desired
effect.  that's all well and good for test cases, but it doesn't help so
much in practice.

hopefully this is another fairly simple fix.  if i were able to delete the
hash key instead of setting it to undef, maybe that would prevent the leak,
but i haven't been able to get that to work at all.

thanks, and let me know if i can provide any other information.

jack





nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About