Re^2: understanding devel::leak

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

I recently learned you can compile your perl with the parameter -DPURIFY which disables perl's own memory pool. This means whenever you release memory it is visible outside the process. Normally freed memory is just available to perl to do new things with. Perl's own pool may also free parts of itself but that's a separate issue from your structures as visible from within your program. This is just an effect of using a language with its own garbage collection.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Comment on Re^2: understanding devel::leak

Replies are listed 'Best First'.
Re^3: understanding devel::leak by nonnonymousnonk (Novice) on Oct 09, 2007 at 17:18 UTC
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	[reply]

Replies are listed 'Best First'.

Re^3: understanding devel::leak
by nonnonymousnonk (Novice) on Oct 09, 2007 at 17:18 UTC

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

[reply]

In Section Seekers of Perl Wisdom