mguyott@mirror.UUCP (Marc Guyott) (12/07/89)
Here is something that Jim Champeaux discovered here at Mirror Systems. I
am curious to learn if anyone else has experienced similar problems.
The basic problem is that calling MakeProcInstance() when it is not needed
[even though Microsoft says it is OK but not necessary to call
MakeProcInstance() in our particular case] even with matching
FreeProcInstance() calls ends up slowly using up all of free memory. It
appears that each call to MakeProcInstance() and FreeProcInstance() uses up
96 bytes of global memory. Our program was crashing due to insufficient free
memory after about 4000 iterations through the code that contained the
MakeProcInstance() and FreeProcInstance() calls. Removing the unnecessary
MakeProcInstance() and FreeProcInstance() calls solved the memory loss
problem. We reported this to Microsoft via On-Line but we have not yet heard
anything from them.
Marc
----
"All my life I always wanted to BE somebody.
I see now I should have been more specific."
Jane Wagner
Marc Guyott mguyott@mirror.tmc.com
{mit-eddie, pyramid, harvard!wjh12, xait}!mirror!mguyott
Mirror Systems Cambridge, MA 02140 617/661-0777
----
/* Written 2:01 pm Dec 4, 1989 by jvc@prism.TMC.COM */
/* ---------- "Global Memory Loss" ---------- */
Read this if your are experiencing global memory loss.
According to Microsoft, MakeProcInstance() "is not required if the
module has a single data segment for all instances". DLLs are
such a creature. However, it seems their wording is not strong
enough. We (tools group) have found that it might actually be
detrimental to use MakeProcInstance() in a DLL.
WinTester had this problem of eating up global memory. It would
keep allocating 96 byte blocks of memory to support a linked list.
From what we can tell this linked list contained nothing but nulls.
In our case, we were also not using FreeProcInstance() since Microsoft
also states "MakeProcInstance can create no more than one procedure
instance of an application. This means that after a procedure instance
has been created, subsequent calls using the same function and instance
return the same result.". We only had four or five functions which needed
(we thought) procedure instance addresses and these functions were called
repeatedly. Well, we installed FreeProcInstance() in all locations
appropriate and the same problem continued.
We finally removed the MakeProcInstance()/FreeProcInstance() calls
(remember, Microsoft said they weren't required) and used the address
of the function directly. Problem solved, no more eating global
memory.
/* End of text from prism:ms.clps.common */mrys@ethz.UUCP (Michael Rys) (12/08/89)
In article <33666@mirror.UUCP> mguyott@prism.TMC.COM (Marc Guyott) writes: >Here is something that Jim Champeaux discovered here at Mirror Systems. I >am curious to learn if anyone else has experienced similar problems. > >The basic problem is that calling MakeProcInstance() when it is not needed >[even though Microsoft says it is OK but not necessary to call >MakeProcInstance() in our particular case] even with matching >FreeProcInstance() calls ends up slowly using up all of free memory. It >appears that each call to MakeProcInstance() and FreeProcInstance() uses up >96 bytes of global memory. Our program was crashing due to insufficient free >memory after about 4000 iterations through the code that contained the >MakeProcInstance() and FreeProcInstance() calls. Removing the unnecessary >MakeProcInstance() and FreeProcInstance() calls solved the memory loss >problem. We reported this to Microsoft via On-Line but we have not yet heard >anything from them. > Marc [stuff deleted] A year ago I was working on a MS-Windows application. When I left, one of the few remaining bugs was, that Windows was eating little junks of memory in undetermined time intervals. The guy who took over my project finally got an explanation by Microsoft (after I tried 3 months to get one) which seems to match with the case above. There were some other problems due to bugs in Windows 2.10 which finally found an explanation by MS (after waiting for a long time). [On the other hand MS explained a lot more in very short time...]. Cheers.../Michael +---------------------------------------------------------------+ | Michael Rys, V. Conzett Str. 34; CH-8004 Zuerich; Switzerland | +---------------------------------------------------------------+ | UUCP: mrys@ethz.UUCP or EAN: mrys@ifi.ethz.ch | | mrys@bernina.UUCP IPSANet: mrys@ipsaint | | Voice: +41 1 242 35 87 | +---------------------------------------------------------------+ -- Wovon man nicht sprechen kann, darueber muss man schweigen. -- Ludwig Wittgenstein, Tractatus logico-philosophicus
lau@scrolls.wharton.upenn.edu (Yan K. Lau) (12/12/89)
In article <33666@mirror.UUCP> mguyott@prism.TMC.COM (Marc Guyott) writes: >Here is something that Jim Champeaux discovered here at Mirror Systems. I >am curious to learn if anyone else has experienced similar problems. > >The basic problem is that calling MakeProcInstance() when it is not needed >[even though Microsoft says it is OK but not necessary to call >MakeProcInstance() in our particular case] even with matching >FreeProcInstance() calls ends up slowly using up all of free memory. It I had a problem with Make/FreeProcInstance. I was running a timer that would bring up a pop-up every few minutes. The pop-up was very simple, just a message with an OK icon. The problem occurs if the user doesn't click on the OK before the next pop-up is due. Since only one pop-up message is correct, I didn't want to stack the pop-up windows (also it would run out of memory and crash if there were too many). So, I checked to see if there was already a pop-up displayed. If so, I sent the equivalent of a OK to that message first and then created the new pop-up. Debugging through the comm port, I found some very wierd behavior. It turns out that FreeProcInstance wasn't being executed when I signal the OK. Therefore, when the user clicked, *all* FreeProcInstances would execute in reverse order. I never had any code after the FreeProcInstance, so I don't know what would have been done next. On another memory problem, does anyone know the proper way to "zoom" graphics? I've tried telling windows that the physical dimensions of the display is twice (for example) what it actually is and changing the origin. This works to some extent but eventually things mess up. For instance, some arcs will not appear, or they will appear but be thicker than they should be. Eventually, the program will crash. Any ideas? Yan. )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ 128.91.11.233 University of Pennsylvania /\ Darker grows the moon And shadows steal across the prison of my room