I've just added an undef ....; to the end of all relevent functions to correspond with all the my ......;

Whether undef-ing works, depends on what exactly you undef. In the trivial example above, undef $h at the end of the loop wouldn't help (as that's implicitly happening anyway), while undef %$h, undef $h->{myself} or delete $h->{myself} would help. Point is that you have to break the circle before the data structure becomes unreachable...

In real life, self-referencing circles are often not immediately evident, as they may come into being indirectly through several data structures, e.g. A references B, which references C, which ... references A — or some such. Your ref counts > 1 might hint at such a situation, unless you have another good explanation for them :)

Sometimes (if all else fails), it helps to step by step disable parts of the program, until the problem goes away. In this case, look more closely into whatever that last part was, etc. — Without seeing any actual code, it's hard to come up more specific tips.

Ever tried Devel::Cycle? I'm using it myself right now for finding a memory leak in a long-running POE application.

Hm, I'm not quite sure how to read your post — I can see three possible ways:

(a) it's just a rhetoric question, to inform people of the existence of the module,  (b) you'd like to know whether I'm personally aware of it / have used it with success,  (c) you're experiencing problems yourself with using it to debug your POE application, and would like to talk more about it.   Or, maybe another one: (d) I've myself had too much exposure to psychology, and am approaching this in a way too complicated manner... ;)

Anyhow, here are my individual replies:

(a)  Thank you for pointing it out!
(b)  Yes, I've tried it in a number of cases, and found it very useful.
(c)  Which problems are you having (if any)?
(d)  Well... you make your guesses :)


BTW, while we're at it, there are (at least) two other modules worth mentioning in this context: Object::Destroyer and Devel::Monitor.