VMalloc error

[George Vagenas]

Error: #3096: Memory allocation failure.  Out of memory for strings
Script: Text = strreplace(Text, 'Program Files\', 'program files x86)\')
Assignment: text
File: C:\0ser\WinBatch\Macros\Noodling\OneShot.wbt
Procedure:
Line No. 7

I received this error and thought that by exiting Studio and restarting it would be fixed, not!  Apart from logging off or restarting is there a fix for this problem.

[Deana]

Based on your description it sounds like you've burned up a whole bunch of your string space. Basically you have something in the program using large string variables to the point where it exceeds the design goals of the language.

If you need to hold LARGE variables or entire files, consider using the Binary Buffers instead. The Binary commands are able to utilize the string space more efficiently. Binary Buffers hold large amounts of data. Allocate a LARGE binary buffer at the beginning of your program. BinaryPokeStr all needed variables into reserved spots in Binary Buffer, drop all variables except binary buffer handle, then reload variables with BinaryPeekStr.

If you need further assistance, please post a full description of the script, the source code and DebugTrace output .

[kdmoyers]

Error: #3096: Memory allocation failure.  Out of memory for strings

speaking for myself only, when I see this, I start looking for a looping bug in my code that is burning up string space.

just my $0.02,
Kirby

[Deana]

Error: #3096: Memory allocation failure.  Out of memory for strings

speaking for myself only, when I see this, I start looking for a looping bug in my code that is burning up string space.

just my $0.02,
Kirby

Good point. Loops are a good place to start. Also look for FileGets on really large files.

[td]

Recursive UDF/S calls in another 'good' way to get into string table purgatory.
(I mention the above as the result of first hand experience...)

[George Vagenas]

Only a controlled for/next loop involved and 159 path strings.  Largest path string was "C:\0ser\WinBatch\Macros\Studio PrjMngr\PrjMngr Working2.wbt".  A total size of 9540 bytes, if all the paths were this lengths, which I believe is well within the Winbatch string memory imits.

Code (winbatch) Select Expand

   intcontrol(73, 1, 0, 0, 0)   ; GOTO error handler.
   Files = strreplace(strreplace(clipget(), @crlf, @lf), @lf, @tab)
   Cnts = itemcount(Files, @tab)
   for Cnt = 1 to Cnts
      File = itemextract(Cnt, Files, @tab)
    Text = fileget(File)
      Text = strreplace(Text, 'program files\', 'program files (x86)\')
      fileput(File, Text)
   next ;Cnt


At any rate I take it the implied answer to the unanswered question is no.

[JTaylor]

Does it occur if you run it outside of Studio?   How big are the files you are changing?   If scripts I assume not too big but thought I would ask.   Not that it helps but I tried this on a list of files in studio and didn't get an error so guessing it is something with the data rather than Studio or the Script...unless something is corrupted with your install of Studio, of course.

Jim

[Deana]

Only a controlled for/next loop involved and 159 path strings.  Largest path string was "C:\0ser\WinBatch\Macros\Studio PrjMngr\PrjMngr Working2.wbt".  A total size of 9540 bytes, if all the paths were this lengths, which I believe is well within the Winbatch string memory imits.

Code (winbatch) Select Expand

   
   Files = strreplace(strreplace(clipget(), @crlf, @lf), @lf, @tab)
   Cnts = itemcount(Files, @tab)
   for Cnt = 1 to Cnts
      File = itemextract(Cnt, Files, @tab)
    Text = fileget(File)
      Text = strreplace(Text, 'program files\', 'program files (x86)\')
      fileput(File, Text)
   next ;Cnt


At any rate I take it the implied answer to the unanswered question is no.

I suspect this line is the culprit:

Code (winbatch) Select Expand

Text = fileget(File)

It attempts to read the entire file contents into a string variable.  That file is too large. Try using a different method to replace strings like BinaryRead and BinaryReplace.

As for an 'unanswered question', I assume you are referring to your query "Is there a fix to the problem?". I believe that question was answered in all of the replies. I specifically stated that FileGet could be a culprit.

Here is a UNDEBUGGED code sample:

Code (winbatch) Select Expand

intcontrol(73, 1, 0, 0, 0)   ; GOTO error handler.
Files = strreplace(strreplace(clipget(), @crlf, @lf), @lf, @tab)
Cnts = itemcount(Files, @tab)
for Cnt = 1 to Cnts
      File = itemextract(Cnt, Files, @tab)
      handle = BinaryAlloc(FileSize(File)+100)
      BinaryRead( handle, File )
      BinaryReplace( handle, 'program files\', 'program files (x86)\', 0 ) ; not case sensitive
      BinaryWrite( handle, File )
      BinaryFree(handle)
next ;Cnt
Exit

[George Vagenas]

Jim thanks but its not the data.  The filter I used to get the file list was "*.wbt", so we're just dealing with text files.

Deana thanks but the largest file was 632 KB, no where near the 250 MB limit, so I feel the use of FileGet was appropriate.  At any rate if I occurs again I'll try to track it down but right now the move from XP to Win7 is my priority.

[Deana]

The 3096 error occurs when WinBatch is unable to allocate a sufficiently large chunk of data needed to store a string. Getting rid (dropping) of large strings helps. I posted a suggested work around using binary operations. Did that resolve the error?

Also check out: http://windows.microsoft.com/en-us/windows/preventing-low-memory-problems#1TC=windows-7

[George Vagenas]

After the error I rebooted and ran the search again.  I used the same code to replace the text in the returned list so there's no way to retest.

I did look at your code and I also had the same thought that as you suggested, I should have dropped the variable before reentering the loop.