Unrecoverable Error 5302 Conventional Memory Exhusted

[fbizzell]

I get this error when running a Clipper 5.2e application on a Windows 98 machine:

Unrecoverable error 5302 Conventional Memory Exhausted

I do not get this error when running it on a Windows 2000 or Windows XP. I have the following statement in the autoexec.bat file on the win98 machine:
SET CLIPPER=F200;E0

I am using Blinker 7.0

It does not happen all the time but very frequently in one section of the program.

 

[JockMullin]

Hi, fbizzell

If you do a mem in a command window on the win98 machine, it should indicate the largest executable program size. Also note if it indicates any free expanded (EMS) memory.

Compare that with mem output in a cmd prompt on the Win XP machine. Win 98 is often a lot less. If so, you can try tweaking the config.sys and autoexec.bat to remove drivers or move them to high memory and free up more conventional.

If there is EMS available, remove the E0 on your set clipper (or set it to a value) and see if that helps free up some conventional memory for clipper. EMS (usually) works reliably on a well configured Win98 box.

Your app is likely tight on memory in the existing setup and craps out when it can't allocate additional under some operational circumstances.

Jock

 

[TonHu]

Removeing E0 from the set CLIPPER line when EMS memory is available, will il almost all cases cause corrupt indexes on your databases, so you'd better leave that setting there.

Other clues are indeed most plauusible.

HTH
TonHu

 

[fbizzell]

HERE IS RESULT OF RUNNING MEM /C ON WIN 98 MACHINE:


Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 24,080 (24K) 10,624 (10K) 13,456 (13K)
HIMEM 1,104 (1K) 1,104 (1K) 0 (0K)
EMM386 4,320 (4K) 4,320 (4K) 0 (0K)
ANSI 4,320 (4K) 4,320 (4K) 0 (0K)
DBLBUFF 2,976 (3K) 2,976 (3K) 0 (0K)
WIN 3,744 (4K) 3,744 (4K) 0 (0K)
vmm32 45,312 (44K) 1,648 (2K) 43,664 (43K)
COMMAND 10,528 (10K) 10,528 (10K) 0 (0K)
BREQUEST 34,544 (34K) 34,544 (34K) 0 (0K)
IFSHLP 2,864 (3K) 0 (0K) 2,864 (3K)
Free 581,152 (568K) 581,152 (568K) 0 (0K)

Memory Summary:

Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 655,360 74,208 581,152
Upper 59,984 59,984 0
Reserved 393,216 393,216 0
Extended (XMS) 66,000,304 ? 131,481,600
---------------- ----------- ----------- -----------
Total memory 67,108,864 ? 132,062,752

Total under 1 MB 715,344 134,192 581,152

Largest executable program size 581,056 (567K)
Largest free upper memory block 0 (0K)
MS-DOS is resident in the high memory area.

HERE IS RESULT OF RUNNING MEM /C ON XP MACHINE:


Conventional Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 12080 ( 11.8K) 2F30
KBD 3296 ( 3.2K) CE0
HIMEM 1248 ( 1.2K) 4E0
BTRDRVR 320 ( 0.3K) 140
COMMAND 4064 ( 4.0K) FE0
BREQUEST 35344 ( 34.5K) 8A10
VIPX 1120 ( 1.1K) 460
VLMSUP 15216 ( 14.9K) 3B70
FREE 112 ( 0.1K) 70
FREE 582304 (568.7K) 8E2A0

Total FREE : 582416 (568.8K)

Upper Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 180208 (176.0K) 2BFF0
MOUSE 12528 ( 12.2K) 30F0
MSCDEXNT 464 ( 0.5K) 1D0
REDIR 2672 ( 2.6K) A70
DOSX 34848 ( 34.0K) 8820
FREE 1248 ( 1.2K) 4E0
FREE 95568 ( 93.3K) 17550

Total FREE : 96816 ( 94.5K)

Total bytes available to programs (Conventional+Upper) : 679232 (663.3K)
Largest executable program size : 581024 (567.4K)
Largest available upper memory block : 95568 ( 93.3K)

1048576 bytes total contiguous extended memory
0 bytes available contiguous extended memory
941056 bytes available XMS memory
MS-DOS resident in High Memory Area

 

[JCreamerII]

fbizzell,

You can also test the amount of free pool memory available at different points in the program by using the "MEMORY()" function; three different parameters available MEMORY(0) - Estimated total space available for character vaules, MEMORY(1) Largest contiguous block available for character values, MEMORY(2) Area available for RUN Commands. Back in the old days I used to use it to figure out whether or nor I was going to have a problem with a machine.

Jim C.

 

[JockMullin]

Hi, Fbizzell

Those two machines appear to have equivalent free memory. In the WIN98 machine you could drop ansi.sys and pick up 4K, which likely won't make much difference, but you never know. Unless of course you are using ANSI control codes for the video display in the DOS box.

I see it is a Netware/Btrieve setup. I guess your app is using Btrieve, or is it there for another purpose? If you're not really using Btrieve then you should be able to eliminate BREQUEST, which would help a lot.

It's been quite a few years, but as I recall there is a startup option on the Btrieve requestor which will make it free up memory after each request. That might help, though at a penalty in terms of performance; possibly not all that much depending on the application.

No EMS, so nothing to gain there though as TonHu pointed out that might be dicey anyway, though if you are accessing data via Btrieve you shouldn't have to worry about index corruption.

Jock

 

[fbizzell]

Thanks everyone for all their comments so far.

We must run brequest because our Clipper application reads and writes data to our accounting software whose datafiles are btrieve data files. We also run Advantage Database Server for our clipper databases and that cuts down on corruption problems.

After making some of the suggested changes in our win98 autoexec and config.sys files we have noted some improvement but still have errors crop up as conventional memory exhausted.

The ansi.sys may be needed by the accounting
application...I am not sure but will check that out.

I am wondering if part of my problem may be the use of public variables vs local variables. Which one requires less memory? I tend to use public more than local.

 

[JCreamerII]

fbizzell,

Variables are variables but, locals are held in memory only while that procedure is working. Public can be available through out the app, depending how & when they are called and released.

Jim C.

 

[JockMullin]

Using local variables can reduce the overall data size, though often at the expense of having it become fragmented and requiring frequent cleanup, where clipper 5 may have problems if memory is tight.

If your app uses public variables then the overall symbol table size will be more static, so then you have to try to reduce the total number of variables in use, such as by using arrays, and also be sure to release the data area when finished. For example, if you are saving the screen image to a variable, once you are finished with the image, set the variable back to a null string.

The other quick way to reduce a program's footprint is to reduce the number of literals in the prog. In a business app you may have many occurrences of "pic '###,###.##'" or "hit any key to continue". Replacing all those with a public memvar may reduce the code size. As soon as it gets below a 2K or 4K boundary (forget which) then that 4K becomes available for use elsewhere.

When your app is crashing, are you getting a traceback? If so then you can determine what kind of operation is causing the memory exhaustion. If it is when trying to allocate memvar space, then that points you to too many variables, too much data in memory or a memory leak. If it is happening when doing I/O then there may be a problem allocating data buffers.

I did research the startup option on brequest I mentioned earlier, but it turns out it is on the server side and relates to server memory usage, not workstation, so nothing to be gained there.

Jock

Jock