I know from personal experience that there is a memory handling problem in win32-gui.
I had an application that could be turned on or put into "pause" mode - which meant it would not do any processing until the start button was clicked. This application would drag any computer I put it on to a halt. The time it took to do this depended on how much memory the machine had to start with. It seems to me that if this problem only concerned windows cache allocation, that it would not make the box grind to a halt. I will admit that I do not understand the intricacies of how windows handles memory, but I did want to add my personal experiences in hopes it may shed light on the problems. HTH, [EMAIL PROTECTED] -----Original Message----- From: Sam [mailto:[EMAIL PROTECTED] Sent: Sunday, January 07, 2001 9:32 PM To: [EMAIL PROTECTED] Subject: [perl-win32-gui-users] Memory leak (not really a leak at all) -----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- [EMAIL PROTECTED]/. 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 _______________________________________________ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
