Program compiled by PBwin9 needs more machine memory than by PBwin8?

[Houng Chang]

I have a situation here: The PBwin program that I have been working on since Turbo Basic is experiencing the memory issue under PBwin9. Under PBwin8, the compiled program can run on Windows XP on 0.5G- or 1G-memory PC. But compiled by PBwin9, when the program starts to read data into arrays (15 one dimensioal array (900 elements, string or single), the following message from PB shows up:

[ The instruction at "0x00432d2e" referenced memory at "0x0065a000". The memory could not be "written".
Click on OK to terminate the program. ]

Anyone has the similar situation? Solutions? (using PBwin9)

HYC

[Steve Rossell]

This error from your OS does not mean that version 9 uses more memory then version 8, what it means is you are accessing memory that does not belong to your process. It is very likely that this error was in your code in version 8, but was not exposed until you compiled with the new version. Any new version of the compiler will place things in different memory locations than the previous version(s). I would run your code in the debugger or insert a

#DEBUG DISPLAY ON

in your code.

[Houng Chang]

Steve,

With #DEBUG Display ON, the message is:

Untrapped Error #7 (Out of memory) has occurred following execution of SELECTCO
Press OK to continue, Cancel to terminate

On a 0.5G or 1G-memory PC with WindowsXP, when the SELECTCO reads a short file, the execution is fine. When the SELECTCO reads a long file, the message shows up.

On a 2G Windows Vista PC, the execution is totally OK.

This is not a critical issue for me, but just to report the situation.

HYC

[Barry Erick]

Steve, Steve, Steve:

Then vs. than:

I'd rather do this first, then go and do something else.

I would rather work on programming than go bowling.

[Barry Erick]

Steve,

With #DEBUG Display ON, the message is:

Untrapped Error #7 (Out of memory) has occurred following execution of SELECTCO
Press OK to continue, Cancel to terminate

On a 0.5G or 1G-memory PC with WindowsXP, when the SELECTCO reads a short file, the execution is fine. When the SELECTCO reads a long file, the message shows up.

On a 2G Windows Vista PC, the execution is totally OK.

This is not a critical issue for me, but just to report the situation.

HYC

This is a bug in your program. You could also try the #OPTOMIZE options. But I'd look at where you are storing this stuff.

[Michael Mattias]

>When the SELECTCO reads a long file, the message shows up.

Um, exactly how long is a "long" file? Are you trying to read the entire file contents into memory? (code not shown).

[Michael Mattias]

FWIW....

On a 0.5G or 1G-memory PC with WindowsXP, when the SELECTCO reads a short file, the execution is fine. When the SELECTCO reads a long file, the message shows up.

On a 2G Windows Vista PC, the execution is totally OK.

The amount of installed RAM is not the only factor in determining the availability of virtual memory. The amount of virtual memory available to your process is also regulated by your page file size.

If your page file is not allowed to grow enough, you can get an "out of memory" situation even though your process is far below its nominal allowance of 2 Gb.

And since the page file is a shared resource, other processes can affect the amount of virtual memory your program will be allowed to allocate.

I think you should add a couple of calls/reports using the GlobalMemoryStatus() or GlobalMemoryStatusEx() functions to report the memory available to your process.

Well, that, and do a little more comprehensive job of error-trapping.

MCM

[John Gleason]

Barry, technically speaking, that would be #OPTIMIZE.

[Michael Mattias]

>Barry, technically speaking...

John, technically speaking neither #OPTIMIZE nor #OPTOMIZE will do anything to handle a failed memory allocation, unless #OPTOMIZE/#OPTIMIZE "SPEED" gains speed by eschewing error checking for such a failure - which I simply refuse to believe.

And should I have made a poor assumption, I will wager anyone thirty-seven cents this program would fail later anyway. I'll even give you two-to-one odds on that.

[John Petty]

"Out of Memory" a totally usesless error message, was common in 9X but usually didn't mean that at all, just that an OS table had run out of handles, ie too many window handles (every control is a window). Most of these small limited tables were removed in NT though limits can still be hit particularely if using the 3G switch, particularly the page file and VM address tables.
By default XP will adjust the size of the Page File to match the need (though it does have a maximum size not sure if it is 2G or 4G) but I believe (but not sure) that the adressing table for it has to fit in resident memory.
The OP gives very specific sizes for his arrays but says file sizes read into them can be vastly different so I have to guess the difference is the length of the strings. Bob would have to answer if there has been a major change in memory usage in that area between 8 and 9 though I doubt it.
Personally I think XP running in .5g of memory is marginal for large programs with data and I suspect that the OP had just not used as big a file with 8.

[Michael Mattias]

>Out of Memory" a totally useless error message

I beg to differ.

"Why" the memory did not allocate is not important; what IS important is, the compiler COULD NOT ALLOCATE and so it returned an "Out of Memory" error.

I'd suggest there are but two choices for the error text for error 7:

1. "Out of Memory"
2. "Unable to Allocate Virtual Memory"

Given PowerBASIC's general user base, which do YOU think the better text?

MCM

[John Petty]

My comment was not meant to be a criticism of PB as I believe error 7 is a generic OS generated error with that description so there is no other way I can think for PB to describe it.
As I said in 9X in particular it often had nothing to do with actual memory allocation just a handle table being full as per the windows handle example I gave, that was the error message even if the OS was still able allocate plenty of memory when all that had actually happened was that the 64K fixed maximum size for window handles was full even though there was still free memory and space in the memory tables.

[Houng Chang]

John, Michael,

I examined the code and found what happened is the handling of list box contents by PB9 and PB8 "maybe" different.

I intended to list 900 string lines (100 characters each line) in the list box. PB8 can handle up to 500 lines which is what I had so far.
PB9 run out of memory for the list box content up to 50 lines of string.

HYC

[Steve Rossell]

I had no problem adding 10,000 100 character length strings to a listbox control.

#Compile Exe
#Dim All

%IDC_LISTBOX1 = 1001

Function PBMain()
  Local hDlg  As Dword

  Dialog New 0, "Dialog1", 233, 254, 201, 121, To hDlg
  Control Add ListBox, hDlg, %IDC_LISTBOX1, , 5, 5, 175, 100

  Dialog Show Modal hDlg, Call DlgProc
End Function

CallBack Function DlgProc
  Local i As Long

  Select Case As Long Cb.Msg
    Case %WM_InitDialog
      For i = 1 To 10000
        ListBox Add Cb.Hndl, %IDC_LISTBOX1, Repeat$(100, "A")
      Next i
  End Select
End Function

Can you show or send failing code to support @ powerbasic . com?

[Michael Mattias]

You know guys, that adding the strings to the listbox may NOT be where the problem lies... as Steve as shown.

Memory allocation failures - or any error for that matter - if not handed IMMEDIATELY can cause later program failures at unexpected times.

At this point I would be a lot of money this is exactly what is happening... some error occured and was not handled immediately.

MCM

[Houng Chang]

Steve, Michael,

The code has 8200 lines (including comment and blank lines). I will strip out the uncessary parts and send it this weekend. Thanks,

HYC

[Michael Mattias]

Wait a minute... first thing, how did you handle that "out of memory" situation? Did you exit the program, do something else, or did you just let it keep running? Letting it run is EXACTLY the kind of thing which can cause these 'surprise' errors.

[John Petty]

You know guys, that adding the strings to the listbox may NOT be where the problem lies... as Steve as shown.

Memory allocation failures - or any error for that matter - if not handed IMMEDIATELY can cause later program failures at unexpected times.

At this point I would be a lot of money this is exactly what is happening... some error occured and was not handled immediately.

MCM

Totally agree. From what has been posted these are not large amounts of data at all so would not expect error 7. A wild guess would be an unhandled FPU error on the 50th item so it is trying to add a string of infinate size to the list box or to an inifinite position in the list box.

[Cliff Nichols]

In the words of the most basic "Code not shown"
We could speculate all day and night for weeks on end and not find it because not even the application, nor example are show....so could it be a memory swap? could it be a low memory usage? could it be the idea the moon rose in the west??? who is to know?

[Houng Chang]

OK, problem resolved:

1) Program error (or you can say my error) for so many years in there through PBDK, PB7, PB8)
2) PB9-compiled on Windows XP just quit.
3) The following program based on Steve's List box tells the story:

The function STRING$((28-LEN(names)),95) is where causes trouble. If Len(names) is greater than 28, PB8 and earlier-compiled somehow just let it go through. But PB9-compiled on XP just quit.

Thanks, Steve, Michael, John, Cliff, and all readers.

HYC


(Somehow I need to learn how to put the following program into a list box.


#COMPILE EXE
#DIM ALL

%IDC_LISTBOX1 = 1001
%IDOK = 1
%IDCANCEL = 2
%BS_DEFAULT = 1


FUNCTION PBMAIN()
LOCAL hDlg AS DWORD

DIALOG NEW 0, "Dialog1", 20, 20, 600, 320, TO hDlg
CONTROL ADD LISTBOX, hDlg, %IDC_LISTBOX1, , 5, 5, 580, 280

CONTROL ADD BUTTON, hDlg, %IDOK, "OK", 30, 290, 40, 14, _
%BS_DEFAULT OR %WS_TABSTOP CALL OkButton
CONTROL ADD BUTTON, hDlg, %IDCANCEL, "Cancel", 80, 290, 40, 14 _
CALL CancelButton

DIALOG SHOW MODAL hDlg, CALL DlgProc
END FUNCTION

CALLBACK FUNCTION DlgProc
LOCAL i AS LONG
DIM ga AS STRING
DIM Textt AS ASCIIZ * 255
DIM sym AS STRING, names AS STRING, groupnum AS LONG, gpname AS STRING, dummy AS STRING

SELECT CASE AS LONG CB.MSG
CASE %WM_INITDIALOG

'' p1001tt.csv is the data file which can be created by using Excel.
OPEN "p1001tt.csv" FOR INPUT AS #1
FOR i = 1 TO 490 '' 00
INPUT#1,sym,names, groupnum,gpname,dummy,dummy,_
dummy,dummy,dummy,dummy,dummy,dummy,dummy,dummy,dummy
ga=MID$(STR$(groupnum),2,2)+MID$(STR$(groupnum),4,1)+MID$(STR$(groupnum),6,1)+MID$(STR$(groupnum),8,1)
textt=STR$(10000+i)+STRING$((6-LEN(STR$(123))),95)+ga+STRING$((8-LEN(ga)),95) +sym+STRING$((7-LEN(sym)),95)+names+ _
STRING$((28-LEN(names)),95) + gpname+ STRING$((38-LEN(gpname)),95)
LISTBOX ADD CB.HNDL, %IDC_LISTBOX1, textt ''Repeat$(100, "A")
NEXT i
CLOSE #1
END SELECT
END FUNCTION

CALLBACK FUNCTION CancelButton () AS LONG
IF CB.CTLMSG = %BN_CLICKED THEN
DIALOG END CB.HNDL, 0
FUNCTION = 1
END IF
END FUNCTION

CALLBACK FUNCTION OkButton () AS LONG
IF CB.CTLMSG = %BN_CLICKED THEN
DIALOG END CB.HNDL, 1
FUNCTION = 1
END IF
END FUNCTION