All Forums >> [Scripting] >> Post a VBScript >> VBScript memory leaks Do you like VisualBasicScript.com? Link to us and help spread the word about our forum. Thanks!
An important issue that has been ignored/overlooked in my opinion is the issue with memory leaks. In 99% of situations this isn't an issue, but if you ever plan to use your scripts in an HTA, or any other envireonment where it will be open for more than a few minutes than this will apply to you:
First off, what is a memory leak?
A memory leak is a particular kind of unintentional memory consumption by a program where the program fails to release memory when no longer needed. resulting in that program subsequently losing the ability to access it due to program logic flaws.
So what are consequences of having memory leaks?
This can result in your entire computer losing its efficiency due to the loss of RAM and virtual memory. So the result of a memory leak is usually an ever growing amount of memory being used by the system as a whole, not merely by the erroneous process or program. Like I said earlier, in most cases this isn;t an issue whent he program only runs for short periods of time, but when you start to build higher end applications it will pose a significant issue. For example, I'm developing a large database manipulation application for the Logisitics guys here in Iraq, but because of its memory leaks it will crash if its left on overnight. Nothing technically wrong with the programming itself, but an inherent problem with how memory allocation is handled by MSHTA.exe (garbage collecting) is whats causing the issue.
So what does it look like?
Heres a simple example of a vbscript that will cause a memory leak:
At the end of this script, neither X nor Y have been released because each still has another object referencing it. Yet you now have no way of getting to that memory because all the variable references have been thrown away. This is a circular reference memory leak. Unlike its brother, JScript, vbscript does not have a circular reference detector. but fortunately, as soon as your program closes, this memory leak is corrected, the engine breaks all the circular references and destroys all unterminated objects.
a quote from MSDN for ASP related issues:
quote:
A somewhat more technical problem can arise when using VBScript classes on the ASP Web server. The ASP server is multithreaded and assigns a different thread to each page request (and hence each script engine). But VBScript class instances are apartment-threaded objects, which means that they must run on the thread that created them. Therefore, attempts to use one instance of a VBScript class on two different pages via storage in Session or Application scope are doubly doomed to failure. First of all, since apartment-threaded objects must run on the same thread, but different pages are on different threads, you'll take a major performance hit if you use one object on two pages with Session scope. Any calls on the second thread have to be marshaled back to the first thread, which is both a source of resource contention and simply a slow operation. Putting apartment-threaded objects into Session scope is not recommended, and putting them into Application scope is illegal. However, that point is somewhat moot because, as I mentioned earlier, when the script engine shuts down, all of the objects that it owns are terminated. Remember, the methods of a class are script and therefore need a script engine to run them. When the page associated with the class is served to the client, the script engine that created the class is closed and all the class instances go with it.
Another problem:
Anytime you work with the browser, wether it be Internet Explore or an HTML Application, you have a serious possibility of creating memory leaks that can't be fixed by just closing the program Generally speaking attaching an event to tag elements can create memory leaks since the browser/HTA never knows when it can delete either. Thus, it never does. (it never knows when you're done listening for an event). So a good way to fix it is with something similar to this:
someobject.eventListener = undefined; or someobject.eventListener = Nothing;
This is just an introduction to the problem and the possible solution. If you have more to add please do, I'd like to hear your experiences with this issue
_____________________________
To iterate is human, to recurse divine. -- L. Peter Deutsch
Use for %i in (1,2,3,4,5) do cscript nothing.vbs %i
to call
That will give you something like
From that you see:
(1) Set oX = Nothing will decrement the reference counter of oX. If this counter reaches 0, oX will be destructed and its memory released. The destructor could do other important stuff like closing files or destroying 'big' variables (e.g. a dictionary containing many items). So being able to specify the moment when destruction takes place is valuable (Scripting Guys and their opinions not withstanding).
(2) Circular references make it more difficult to achieve this goal. But it's not impossible. Can you add code to nothing.vbs to get:
cscript nothing.vbs 6 (6) Start of Main After marriage (circular reference) everything works if you work for it. cNothing::Class_Initialize() called. cNothing::Class_Initialize() called. cNothing::Class_Terminate() called for Sec. cNothing::Class_Terminate() called for Frs. End of Main