Microsoft KB Archive/87455

{| The information in this article applies to: - Microsoft Test for Windows, version 1.0
 * width="100%"|

SYMPTOMS
A &quot;Parser out of memory&quot; error occurs when running a Test for Windows, version 1.0 script file under Test Driver.

CAUSE
The &quot;Parser out of memory&quot; error in Test means the Test Driver pseudocode engine has exceeded its memory limit on an object. Three types of objects can cause this error (listed in descending order of probability):


 * 1) Code segment memory (64K)

2. Data segment memory (64K) 3. Parser table memory (tables are variably-sized)

RESOLUTION
Reduce the size of the object causing the error. Resolution depends on the object causing the error. Various methods of working around the error are shown below.

MORE INFORMATION
The &quot;parser&quot; is the part of Test Driver that translates the script code entered by the programmer into machine-language pseudocode and executes it.

Code Segment Memory
The most common cause of the &quot;Parser out of memory&quot; error message is that the script code is larger than the 64K code segment. (One 64K code segment is allotted for each script file.) Solve this problem by dividing your large code script into two or more smaller scripts that are called sequentially from a &quot;driver&quot; script. (For an example of this technique, see the TSTSUITE application in MSTEST\SAMPLES\TSTSUITE. DRIVER.MST is the driver script that calls various other scripts from itself.)

Another technique, which can be used along with the first to shrink code space, is to create a &quot;wrapper&quot; routine. In this case, a wrapper routine is a SUB or FUNCTION that makes only one call to DLLs with large numbers of parameters. Without a wrapper routine, numerous direct DLL calls are made, generating more internal code, especially with DLLs with large numbers of parameters.

Data Segment Memory
The second most probable cause of the &quot;Parser out of memory&quot; error is a data segment memory overflow. If your script has many variables (particularly arrays) and many quoted literal strings (particularly long strings), you probably have run out of data segment memory. If you suspect this has happened, you can:

Remove some quoted string literals, particularly larger ones, and place them into an external data file. Strings can then be read in as needed during run time. If the problem persists, move more quoted literal strings to the external data file. Consider replacing all arrays with their pointer compliments. (This will not work with variable-length string arrays, because they use string descriptors.) For example, if an array of 1000 integers is defined: 'Array syntax: Dim x%(1000) x%(0) = 32767  'Set first element of array to 32767.

You can convert it to its pointer compliment with:

'Pointer Syntax: Dim x As Pointer To Integer Allocate x, 1000 x[0] = 32767   'Set first element of array to 32767.

(Note: Arrays in Test Basic are in the form 0 - (n-1), so the          above array of 1000 elements goes from x[0] to x[999].)

Parser Table Memory
The least probable cause is an overflow of a parser table--a memory area where code elements such as variables, user-defined TYPEs, SUBs and FUNCTIONs, are stored.

A parser table overflow is rare, because code or data segment memory will normally overflow first. However, if you still suspect this, try to reduce the load on each parser table by reducing the number of SUBs or FUNCTIONs in your program, the number of user-defined TYPEs, the number of variables, and so on.
 * }

-

Last reviewed: April 5, 1995

© 1998 Microsoft Corporation. All rights reserved. Terms of Use.