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