Out Of Memory

[AlastairP]

I am getting occassional out of memory messages.
Most of the time, it seems to be related to previewing a PDF in a web browser control.

This one is a little different:
"Program Error" (Message box title)

"Error loading file - record number 75. Header 1 <or one of its members>. Parent : There is not enought memory to complete this operation"

On this form I have 2 x grids, 1 x treeview and 1 x activex Web Browser to preview PDF files

 

[Olaf Doschke]

Error Messages mostly state the truth, only rarely are misinforming.
You may look into record number 75 of the form started (USE the SCX), but most probable there is nothing wrong, anything needing memory in a situation you don't have any more, will cause an ERROR 43.

So you may have a memory leak.

First thing to look at is drive space of the drive with the TEMPFILES. See the drive in SYS(2023) at runtime of your app, not necessarily the drive in %TEMP%.
Second thing to try is give your VFP application more space by SYS(3050).

Then monitor SYS(1016) over time and see when it grows and does not shrink back. You could store the SYS(1016) values into a log table each time before and after using a form.

Bye, Olaf.

 

[ggreen61]

I have also seen this error occasionally in VFP 9. I can retry to open the form and it usually succeeds in opening for edit after closing the error message. The internal stack for VFP probably has not yet cleared and thus the out-of-memory error. At this point the stack clears and now the same form can be edited.

Looking at the SCX via USE as a table, the "offending" record for me is a table reference. In development, the tables are all empty -- my test tables are stored in a different location from the development tables. So it should not be a problem of actual memory. Also my system has 8G of main memory in a Win7 64-bit system which has plenty of memory for VFP; looking at the history of memory usage I do not see any limits coming close to the 2G limit for VFP. So I suspect it is a problem of clearing the stack and a timing issue.

 

[Olaf Doschke]

AlastairP might add, if this error happens at design time or runtime.

If, like in your case, ggreen61, an empty or small table is opened in the record VFP mentions in the out of memory exception, it still might be just the few bytes needed too much to open this table, to create the file handle and memory object for the workarea used. A table is never read in fully anyway, just because it's put into the data environment. So the size of the table doesn't matter.

Also: You can have 16GB, and VFP will at max take 2 of them, as that is the limit for any 32bit application (3GB, if you set a sepcial switch in boot.ini) and they can get used up, too, for example if the application and computer is never closed or shutdown/restarted. There might be nothing about the reported form record, if it never repeats. If this happens regularly in varying places you know it's not a "masked error", an error leading to the misleading out of memory exception. Such things can also happen, but mostly then are reproducable.

Since you mention the viewing of PDFs in a web browser control, you use up RAM for a COM object, this is not managed by VFP and again, in a long run, if you never restart an app, can of course really cause a memory exception.

Bye, Olaf.

 

[AlastairP]

Hi Olaf,
Yes it is during run time. The program is rynning on Windows server 2008 R2 I think 24 or 32 Gigs of memory

Alastair

 

[Olaf Doschke]

As mentioned the vfp app will only take 2GB, further RAM is fine to support more sessions (for remote usage) OS and of course all other processes, services etc. You can still run out of memory.

Bye, Olaf.

 

[dbMark]

Are you using DLLs and either ODBC or ADO? We get such errors on a Windows 2008 R2 server, usually it's when a DLL gets becomes stuck or nonresponsive, possibly due to network connectivity issues (?), doesn't exit and keeps consuming memory until it's almost 1.5GB. SysInternals ProcessExplorer shows which process PID is consuming too much memory and CPU time and we kill it. We never did find out precisely why but it seems to occurs only with our use of ODBC or ADO connections. Or at least those are the ones reporting the error and are the trigger to get us to track down the errant process. If they were working normally the memory usage and CPU time would be minimal.

 

[AlastairP]

We have only just started using ODBC for access to another database, and the errors predate this. I will look into installing SysInternals ProcessExplorer, and seeing if I can identify the problem.

 

[Olaf Doschke]

I just recently had an error 43 (not enough memory to complete this operation) at a customer. This happend on a virtual server with a query returning 100MB of data into a cursor. This is not exceeding a VFP limitation, but RAM per user session is too short. So again an instance of this or similar errors telling the full truth. It doesn't matter how much RAM the server has, if remote desktop sessions limit the available RAM. That limit is not automatically increased or taken care of by swapping out to a swap file. session RAM limit is a hard limit and can be very much lower than physical RAM available, if you want or need to guarantee a certain amount of parallel user sessions.

Bye, Olaf.

 

[AlastairP]

Ah, and our users all connect to the server using remote desktop . . .

 

[Olaf Doschke]

You're very late with that info.

Start Menu/Administrative Tools/Terminal Services Config. On the properties tab click the advanced button. There you'll see resource quotas". You can adjust there the max. memory usage/user.

Bye, Olaf.