Devel::SoapSuds
Oh wait, this isn't the bike forums is it? ;)
Pure-Perl memory leaks are not too common. When they do occur I've found often they're related to an unintentional closure; thinking you've got a lexical passing out of scope when it really still has a reference to it staying in scope somewhere. Leaks caused by faulty XS programming might have greater potential for trouble. Your mileage may vary.
Of course there are other potential issues, and without seeing code we would have a hard time guessing what might be causing your specific problem. How about giving us a small example of the problem? I'm curious to see.
If you are suspicious of a particular variable, you could tie it to a class that carps a message when the variable goes out of scope. Then you could verify that it's happening as you intend. ...or tie it to a class that logs the length every time it's written to. That would also tell you a lot. But for that to be useful, you at least have to have a suspect variable in mind.
...just food for thought.
| [reply] |
I have found Test::Memory::Cycle to be quite essential ... once I understood it. (The output is mostly obtained from Devel::Cycle, and so the most-useful documentation is actually there.)
Memory-cycles show up in the darndest places...
And one more thing: if you aren't using Test::... scripts from the start of the development process, and in every single step through it, boy-howdy are you making things a whole lot harder on yourself! (I've been doing things the hard way for a very long time, as I discovered recently.) The trouble is, as you continue to build an application, stacking layer upon layer upon layer, the potential for errors simply grows. And the nature of those errors, which often materialize in the foundational parts of the system, becomes harder and harder to track. “Memory leak” problems surface as a show-stopper issue at very inopportune times... late in the game... when they have actually existed for weeks and months.
| |