PB apps when Windows is out of Resources!

[Colin Schmidt]

Hello, I had never actually had windows run out of resources before... I’m glad to say though that I was able to save and close everything cleanly, and safely reboot with out a hitch. I guess Win98SE isn’t that bad for stability after all

Any ways, what I did, without realizing it is create a 280MB dynamic array using a user-defined type. I just never occurred to my DOS programming brain that my PB app could ever use up 128MB of ram and 160MB of the swap file. Normally I’d have gotten an out of memory message ages ago.

One of the reasons I am posting this is that what I saw is not what I expected. What I saw was a GPF. I then spent some time stripping my code down trying to find what was causing it. In the end I was able to cause a PGF with just this code:

DIM a(150000,  34, 12) as LONG
MSGBOX “DIM OK”
a(0, 0, 0) = 1

What I found interesting is that the GPF happened after the MSGBOX. It then finally ran though my thick skull to add up how big this array really was… Well actually it was just for curiosity.

So, what PB does when you run out of memory is nothing. The DIM statement (or REDIM) returns normally with no form of message. Then the first time you try to access the dimensioned variable, you get a GPF.

Help File: “A PowerBASIC array may contain up to 4,294,967,295 elements, and the data may occupy as much as all available memory.”

I realize that PB does not expect us to be filling up all the memory, but a notice in the help file mentioning how PB handles running out of memory would be nice anyway

So, if you are playing with any real amount of data at all, you will probably want to perform a check after each and every DIM or REDIM to confirm that the dimension has been successful. To check this simply look at the return value from VARPTR(array(any element)) If the address returned is 0, then you have to know something is up!

And now my second justification for posting this is the following: Our little tiny PB EXEs are attractive to people with older computers. Let’s say someone with a 486 and 8MB of RAM is running your app on Win95a, do they want to see a GPF from you or a nice message saying “Time to upgrade!”

As for me, I guess I’ll be adding disk-caching-of-large-indexes to my database. To bad, it was moving quick in RAM

And that would be my 20 cents,
Colin Schmidt

-------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada

[Lance Edmonds]

So, if you are playing with any real amount of data at all, you will probably want to perform a check after each and every DIM or REDIM to confirm that the dimension has been successful. To check this simply look at the return value from VARPTR(array(any element)) If the address returned is 0, then you have to know something is up!

In Windows, error testing is predominately the responsibility of the programmer - this is quite different from PB/DOS.

Therefore, if your DIM or REDIM failed, then the ERR, ERRCLEAR and/or the ERRAPI system variables will signal an error condition. May I suggest that you peruse the Errors and Error Trapping chapter in the documentation for PB/DLL.

As you have noted, Windows uses Virtual Memory - this means that your app can just keep expanding it's memory usage until the O/S is unable to grab another [large] chunk of your hard disk to expand the swap file.

Once you start running out of virtual memory (or resources), then Windows often exhibits unexpected and often unpredictable behavior. It is unpredictable because other applications and services that are running at the same time may also fail, and these are likely to have some effect on _your_ application - ie, network redirector software crashing, printer drivers failing, etc.

Windows 95/98/2000 allow you to limit the size of the swap file (I'm not sure about NT4), so by giving it an arbitary "low" maximum VM limit (say 64Mb), you can easily start to check your app for behavior problems when DIM's start failing - in fact, anytime your app needs to grab a new chunk of memory you can run into problems - for example, dynamic string allocation can be affected (fixed-length and ASCIIZ occupy fixed locations so are less likely to encounter runtime out-of-memory errors.

In practice, unless your app is very likely to use 100's of MB of memory, this could be an unnecessary test - it's up to you, the programmer, to decide how bullet-proof you want your application to be.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Colin Schmidt]

Colin said:

I realize that PB does not expect us to be filling up all the memory, but a notice in the help file mentioning how PB handles running out of memory would be nice anyway

Lance said:

In Windows, error testing is predominately the responsibility of the programmer - this is quite different from PB/DOS... ...May I suggest that you peruse the Errors and Error Trapping chapter in the documentation for PB/DLL.

Colin now says: Gosh I feel stupid The only section I didn't read.

Colin Schmidt,

------------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada