Re^3: understanding devel::leak

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.

Comment on Re^3: understanding devel::leak Select or Download Code

Replies are listed 'Best First'.
Re^4: understanding devel::leak by jczeus (Monk) on Oct 05, 2007 at 07:18 UTC
Ever tried `Devel::Cycle`? I'm using it myself right now for finding a memory leak in a long-running POE application.	[reply] [d/l]
Re^5: understanding devel::leak by almut (Canon) on Oct 05, 2007 at 12:30 UTC
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.	[reply]
Re^6: understanding devel::leak by jczeus (Monk) on Oct 16, 2007 at 09:42 UTC
You're right. My post was misleading. It was meant to be (a). Sorry! :-) In the meantime, I've given up on finding the memory leak. I'm not even sure it is one, as the OS is able to reclaim it when necessary. But thank you for pointing out `Devel::Monitor`!	[reply] [d/l]