http://qs321.pair.com?node_id=643755


in reply to Re^2: understanding devel::leak
in thread understanding devel::leak

Thank you Monks for the pointers.

After several weeks of bashing my head against this problem I have at last made a breakthrough, of sorts.

Along my voyage of discovery I've tried:
Devel::leak - no use as I've no idea how to recompile on win32 / activestate. I downloaded the source and read the readme but it just left me even more confused.
Devel::Leak::Object - Don't recall why I gave up on that one.
Devel::Cycle - My data structure is pretty complex so it was entirely plausible that I'd looped somewhere. I thought I wasn't using find_cycle right but it turns out there was nothing there to find.
Devel::Monitor - plain doesn't work on win32 / activestate.
Devel::Peek - I sort of understood what this was telling me but not entirely.
Win32::Perfmon - doesn't work for any of the counters that have instances.

In the end all I could do was step through with the degugger looking for patterns in where perls private bytes increased. Not easy due to the way perl grabs memory in 4k chunks. In the end I got down to one suspect package function. I wrote a fake version of this that returns realistic data. Using this I have proved that there are absolutely no memory leaks in my code. I'd be quite please with this if only it did not render 6 weeks effort pretty worthless.

The module causing the problem is Win32::OLE:OPC and the function is SyncRead.

I'll have a brief look inside the package but I think I reached my limit. It's entirely possible that the problem isn't in that package or even in any of it's perl dependancies but elsewhere in OLE or COM.

Bit depressing really.
nonk