Thanks for pointing me to Test::Memory::Cycle. It and Devel::Cycle (on which it's based) appear to work on a predictive basis. If they find no cycles, or only weakened ones, you could expect there to be no memory leaks.

The proposed Test::Weaken checks both before and after the fact to see that the memory was freed. It certainly would be useful in testing the other approach. :-)

I also now find a Devel::Leak, which actually looks at the Perl internals. However, it requires Perl to have been compiled with the -DDEBUGGING flag set, whereas Test::Weaken works on Perl compiled the ordinary way.

Perhaps which approach is best is a matter of specific situation and taste. I'd think the user would want to have modules implementing both approaches available in CPAN and to be able to take their choice. TIMTOWTDI and all that.

I do notice that Devel::Cycle can handle cycles that happen via references to closures, something my code doesn't at this point.

thanks, very helpful, jeffrey

I'm not aware of anything on CPAN, which doesn't mean there isn't anything, but does it differ much from adding a DESTROY { warn "$_[0] is dying" } to a blessed ref? I'm curious to read how it works if nothing else.

You might even post some of it in a code block... it's not like someone would "steal" it or something...

UPDATE: It definitely sounds iteresting to me. And I'd still like to read through it.

It uses trickery from the Scalar::Util module. There were a lot of gotchas involved -- avoiding autovivification and avoiding strengthening weak references by copying. Limitations are that you've got to pass a closure and create the object in that. And it's totally destructive (at least it is when the test is successful). Anything returned by the closure is potentially (and hopefully) gone forever.

Perhaps the most severe limitation is that it can't have references to any globals or any memory which is supposed to hang around -- it's not smart about that, but just assumes everything must go. If there's interest I may in a future version allow the caller to specify exceptions

The basic trick is to create weak references to the strong references and strong references to the weak references, free up the base reference, and see if all the others go to undefined. I've just added some code to make it smart about undefs in the original object.

I'll get it on CPAN in a couple of days, and you'll be able to read the code. It's not long.

jeffrey

Here it is in all its alpha status glory. (It needs some formatting and more comments.) It passes a simple test suite, and has handled very complicated structures from another CPAN project (the reason I originally wrote it). I've applied to PAUSE for the name Test::Weaken.

There does seem to be a bug with the count of the total references, but it does not affect the count of freed references, and therefore fail/succeed reporting is unaffected.

UPDATE: I've removed the code. Test::Weaken is now on CPAN and anyone can see the latest version there. It's still alpha, but it has a start in the way of documentation and there are test scripts, which make good examples.

The version in this post did turn out to have the bug mentioned above, which is fixed in the CPAN version. I was reluctant to post the code but senior monks asked more than once to see it, and this humblest and most unworthy of Sextons was unwilling to refuse. Those who really feel they need to look at my first attempts, can look at earliest versions on backpan.

jeffrey