Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied
    >But PB9-compiled on XP just quit.

    Should not just "quit." Let me try it...
    Code:
     #COMPILE EXE
    #DIM ALL
    
    FUNCTION PBMAIN () AS LONG
        
        LOCAL names AS STRING, S AS STRING
        
        names =  "1234567890123456789012345678901234567890"
        
        S =  STRING$((28-LEN(names)),95)
        
        MSGBOX USING$ ("ERR #  S '&'", ERR, S)
        
    END FUNCTION
    Interesting, sets error 7.
    Possible errors documented for STRING$ function: NONE.
    Error 7 is
    Out of memory - (%ERR_OUTOFMEMORY) - Many different situations can cause this message, including dimensioning too large an array, or running out of virtual memory due to insufficient free disk space for the Windows swap file.
    Methinks EITHER
    A) The documentation for error 7 is incomplete.
    B) The documentation for STRING$ is incomplete
    C) The actually IS a bug in the compiler, setting the wrong error. I think the correct error should be error 5:

    Illegal function call - (%ERR_ILLEGALFUNCTIONCALL) - This is a catch-all error related to passing an inappropriate argument to some statement or function.
    Seems to me a passing a negative length to the STRING$ function would constitute "passing an inappropriate argument to some statement or function. "

    I shall send in a bug report.

    MCM

    Leave a comment:


  • Houng Chang
    replied
    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

    Leave a comment:


  • Cliff Nichols
    replied
    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?

    Leave a comment:


  • John Petty
    replied
    Originally posted by Michael Mattias View Post
    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.

    Leave a comment:


  • Michael Mattias
    replied
    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.

    Leave a comment:


  • Houng Chang
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Steve Rossell
    replied
    I had no problem adding 10,000 100 character length strings to a listbox control.
    Code:
    #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?

    Leave a comment:


  • Houng Chang
    replied
    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

    Leave a comment:


  • John Petty
    replied
    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.

    Leave a comment:


  • Michael Mattias
    replied
    >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

    Leave a comment:


  • John Petty
    replied
    "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.

    Leave a comment:


  • Michael Mattias
    replied
    >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.

    Leave a comment:


  • John Gleason
    replied
    Barry, technically speaking, that would be #OPTIMIZE.

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    >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).

    Leave a comment:


  • Barry Erick
    replied
    Originally posted by Houng Chang View Post
    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.

    Leave a comment:


  • Barry Erick
    replied
    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.

    Leave a comment:


  • Houng Chang
    replied
    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

    Leave a comment:


  • Steve Rossell
    replied
    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
    Code:
    #DEBUG DISPLAY ON
    in your code.

    Leave a comment:

Working...
X