VMalloc error

Started by George Vagenas, April 12, 2014, 03:48:55 AM

Previous topic - Next topic

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.
Thanks

George

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 .
Deana F.
Technical Support
Wilson WindowWare Inc.

kdmoyers

Quote from: George Vagenas on April 12, 2014, 03:48:55 AM
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
The mind is everything; What you think, you become.

Deana

Quote from: kdmoyers on April 14, 2014, 09:16:25 AM
Quote from: George Vagenas on April 12, 2014, 03:48:55 AM
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.
Deana F.
Technical Support
Wilson WindowWare Inc.

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...)
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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
   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.
Thanks

George

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

Quote from: George Vagenas on April 17, 2014, 01:19:27 PM
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
   
   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
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
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
Deana F.
Technical Support
Wilson WindowWare Inc.

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.
Thanks

George

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
Deana F.
Technical Support
Wilson WindowWare Inc.

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.
Thanks

George