perl-win32-gui-users

[perl-win32-gui-users] Memory leak (not really a leak at all)

[Sam <sa...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I found many references to the 'memory leak' in the archived 
messages at http://www.mail-archive.com/perl-win32-
gu...@ht.../.

I believe there isn't a memory leak at all, it appears that the 
memory usage reported by windows task manager includes a 
portion of a windows cache allocated to the program, and that it's 
the cache usage that changes, not the amount of memory that the 
perl interpreter has allocated.
This is based on these observations:
1)	As the memory usage reported by the task manager increases 
the total memory usage does not increase. If you run a compiler or 
something that will allocate memory a bit at a time for a long period 
of time you'll notice that as the compiler's memory usage goes up, 
and so does the total memory usage.
2)	If you minimize the perl-win32-gui app's window the reported 
memory usage goes down to a base value (120K with my perl), and 
every time you minimize the window it goes down to the same 
value. This is _not_ indicative of a memory leak.
3)	If you play with other applications in a similar way you can 
make them exhibit similar behaviour. The reported memory usage 
on other applications (my test was EditPlus) doesn't increase to 
the same extent, but it does increase (more on this difference later).

During the above I looked over the code involved, and attempted to 
isolate a memory leak. So far as I can tell the code is rock solid.


I believe that the difference between a perl-win32-gui application, 
and other pure win32 applications is in the DefWindowProc 
handling. The perl-win32-gui module does call DefWindowProc 
when either you don't have a handler installed, or you return 1, 
however through BoundsChecker I believe that this may not always 
be the case.

I would be interested if someone finds anything else out about this 
problem. Unfortunately I can't spend any more time on this, as it 
appears to me that this isn't a serious bug, at least not something 
that will stop a program from working correctly.



-----BEGIN PGP SIGNATURE-----
Version: N/A

iQA/AwUBOliL8ZsRND2Z+TaWEQJGwgCeMkadt3YnnIh+sC3In8ZbMObH3WkAoPLK
qIBjQIZHm48LYi6tlAehlC+G
=u9/m
-----END PGP SIGNATURE-----

Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz

Re: [perl-win32-gui-users] Memory leak (not really a leak at all)

[Reini U. <ru...@sb...>]

Have you tried Devel::Leak ?

It works better with a -DDEBUGGING perl version which I currently 
don't have for MSVC.

Sam wrote:
> I believe there isn't a memory leak at all, it appears that the
> memory usage reported by windows task manager includes a
> portion of a windows cache allocated to the program, and that it's
> the cache usage that changes, not the amount of memory that the
> perl interpreter has allocated.
>
> During the above I looked over the code involved, and attempted to
> isolate a memory leak. So far as I can tell the code is rock solid.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html

Re: [perl-win32-gui-users] Memory leak (not really a leak at all)

[Aldo C. <da...@pe...>]

Sam wrote:
> Hi,
>
> I found many references to the 'memory leak' in the archived 
> messages at http://www.mail-archive.com/perl-win32-
> gu...@ht.../.

> I believe there isn't a memory leak at all, it appears that the 
> memory usage reported by windows task manager includes a 
> portion of a windows cache allocated to the program, and that it's 
> the cache usage that changes, not the amount of memory that the 
> perl interpreter has allocated.

oh well, I'm really confused now :-)

> This is based on these observations:
> 1)      As the memory usage reported by the task manager increases 
> the total memory usage does not increase. If you run a compiler or 
> something that will allocate memory a bit at a time for a long period 
> of time you'll notice that as the compiler's memory usage goes up, 
> and so does the total memory usage.

yes, this is true.

> 2)      If you minimize the perl-win32-gui app's window the reported 
> memory usage goes down to a base value (120K with my perl), and 
> every time you minimize the window it goes down to the same 
> value. This is _not_ indicative of a memory leak.

this is true too.

> 3)      If you play with other applications in a similar way you
> can make them exhibit similar behaviour. The reported memory usage
> on other applications (my test was EditPlus) doesn't increase to 
> the same extent, but it does increase (more on this difference later).

and this is true, but there are other applications (for example,
the NT Task Manager) which does not exhibit this behaviour, even
if they're left running for a large amount of time. and the Task
Manager updates its contect each second, so is doing something.
but its cache memory never grows up. damn :-(

> During the above I looked over the code involved, and attempted
> to isolate a memory leak. So far as I can tell the code is rock
> solid.

way cool ;-)

> I believe that the difference between a perl-win32-gui application, 
> and other pure win32 applications is in the DefWindowProc 
> handling. The perl-win32-gui module does call DefWindowProc 
> when either you don't have a handler installed, or you return 1, 
> however through BoundsChecker I believe that this may not always 
> be the case.

I'm really interested in this: can you elaborate more on this
point? do I call DefWindowProc too much, or it is not called
when it should be?

> I would be interested if someone finds anything else out about
> this problem. Unfortunately I can't spend any more time on this,
> as it appears to me that this isn't a serious bug, at least not
> something that will stop a program from working correctly.

well, a 4k increment for each mouse movement is quite too much,
so something should be corrected (if it's not totally wrong, it's
surely at least poorly coded :-)

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: [perl-win32-gui-users] Memory leak (not really a leak at all)

[Sam <sa...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Sam wrote:
> > Hi,
> >
> > I found many references to the 'memory leak' in the archived 
> > messages at http://www.mail-archive.com/perl-win32-
> > gu...@ht.../.
> 
> > I believe there isn't a memory leak at all, it appears that the 
> > memory usage reported by windows task manager includes a 
> > portion of a windows cache allocated to the program, and that it's 
> > the cache usage that changes, not the amount of memory that the 
> > perl interpreter has allocated.
> 
> oh well, I'm really confused now :-)
> 
> > This is based on these observations:
> > 1)      As the memory usage reported by the task manager increases 
> > the total memory usage does not increase. If you run a compiler or 
> > something that will allocate memory a bit at a time for a long period 
> > of time you'll notice that as the compiler's memory usage goes up, 
> > and so does the total memory usage.
> 
> yes, this is true.
> 
> > 2)      If you minimize the perl-win32-gui app's window the reported 
> > memory usage goes down to a base value (120K with my perl), and 
> > every time you minimize the window it goes down to the same 
> > value. This is _not_ indicative of a memory leak.
> 
> this is true too.
> 
> > 3)      If you play with other applications in a similar way you
> > can make them exhibit similar behaviour. The reported memory usage
> > on other applications (my test was EditPlus) doesn't increase to 
> > the same extent, but it does increase (more on this difference later).
> 
> and this is true, but there are other applications (for example,
> the NT Task Manager) which does not exhibit this behaviour, even
> if they're left running for a large amount of time. and the Task
> Manager updates its contect each second, so is doing something.
> but its cache memory never grows up. damn :-(
> 
> > During the above I looked over the code involved, and attempted
> > to isolate a memory leak. So far as I can tell the code is rock
> > solid.
> 
> way cool ;-)
> 
> > I believe that the difference between a perl-win32-gui application, 
> > and other pure win32 applications is in the DefWindowProc 
> > handling. The perl-win32-gui module does call DefWindowProc 
> > when either you don't have a handler installed, or you return 1, 
> > however through BoundsChecker I believe that this may not always 
> > be the case.
> 
> I'm really interested in this: can you elaborate more on this
> point? do I call DefWindowProc too much, or it is not called
> when it should be?
I saw a few messages come in that weren't DefWindowProc'd, but I 
think that may have been my fault (ie returned 0 from handler).
Looking at your code it looks like DefWindowProc is called when it 
should be, but there's obviously a problem somewhere. This was a 
bit of a stab in the dark (much like the assumption about the cache 
allocation, but what other answer is there?). My next move will be 
to attempt to recreate this bug in a pure win32 app.

> > I would be interested if someone finds anything else out about
> > this problem. Unfortunately I can't spend any more time on this,
> > as it appears to me that this isn't a serious bug, at least not
> > something that will stop a program from working correctly.
> 
> well, a 4k increment for each mouse movement is quite too much,
> so something should be corrected (if it's not totally wrong, it's
> surely at least poorly coded :-)
I agree, now. There was a posting recently that reported that a perl 
gui app would crash after all available memory was consumed, so I 
will devote some of my time to fixing this problem.

I'll report when I know more.

> cheers,
> Aldo
> 
> __END__
> $_=q,just perl,,s, , another ,,s,$, hacker,,print;
> 
> 
> 
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> 



-----BEGIN PGP SIGNATURE-----
Version: N/A

iQA/AwUBOlruq5sRND2Z+TaWEQKsowCg8YtbBZKJN7ZbK2kfuPN1ayTqKKQAoIfp
3dsqAbirf2z5dM0oe0iY+MLv
=cIST
-----END PGP SIGNATURE-----

Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz