Announcement

Collapse
No announcement yet.

Could this be a PB WIN bug???

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

  • Michael Mattias
    replied
    This could be a problem with preceeding code and the GPF takes a bit longer to display?
    Well, close, but actually it has nothing to do with "displaying."

    What happens is, your coding error corrupts memory... but that doesn't matter until the next time you need and ask for that memory which is when the protection fault occurs.

    Your program stops executing immediately when a protection fault occurs. That's when Windows kicks in the "display" process when you get that screen with the chance to report your problem to Microsoft.

    MCM

    Leave a comment:


  • Michael Mattias
    replied
    My mistake was in thinking the GPF happened at that exact line of code, and not that it could happen a little while before
    Trust me, you are NOT alone.

    If I had a nickel for every one of the posts we've seen here espousing this belief, I would be rich beyond compare.

    And as you have discovered, one common byproduct of this belief is a failure to post all the relevant code when asking for help... since you don't think other code is in fact relevant. But it is!

    MCM

    Leave a comment:


  • Michael Mattias
    replied
    The "best way" is subjective...

    For future reference, one thing you may want to do is turn on the "Break-On-Error" option in the debugger. That will help you nail down array out of bounds errors faster.


    Code:
    #DEBUG ERROR ON
    ........
    FUNCTION FillMyArrays (.....) AS something
    
     ON ERROR GOTO ErrorTrap
        ' --------------------------------
        ' code
        ' --------------------------------
    
    ResumePoint:
      EXIT FUNCTION
    
    ErrorTrap:
      MSGBOX USING$("Error # &" , ERR, ERROR$(ERRCLEAR)) 
      RESUME ResumePoint
    
    END FUNCTION
    MCM

    Leave a comment:


  • Cliff Nichols
    replied
    Alex,
    For future reference, one thing you may want to do is turn on the "Break-On-Error" option in the debugger. That will help you nail down array out of bounds errors faster.

    Leave a comment:


  • Alex Chambers
    replied
    OK - found it!

    In a preceeding SUB before doAnalysis() I had an array out of bounds error. However, it was only being shown in doAnalysis(). My application is very large, so it would have been too much to post all here.

    My mistake was in thinking the GPF happened at that exact line of code, and not that it could happen a little while before.

    Anyhow, sorted now - thanks once again for all your prompt help.

    Alex

    Leave a comment:


  • Edwin Knoppert
    replied
    Do at least:

    ReDim pricetime2(0 To priceitems2)
    ReDim pricedate2(0 To priceitems2)

    And i am also not convinced it's not in here:

    ' code to fill pricetime2() and pricedate2() here - tested OK

    (Which we can't see of course......)

    Leave a comment:


  • Alex Chambers
    replied
    Ok, thank you. This could be a problem with preceeding code and the GPF takes a bit longer to display? I will check out...

    Alex

    Leave a comment:


  • Richard Angell
    replied
    Your small code sample, even with a change of Sub MainLoop to Function PBMAIN does not produce errors on my ME system. However with the code supplied, there are not enough values to trip the message box in the IF statement. Adding some to trigger the IF MsgBox calls sil does not produce errors.

    You may need to zip the code and send to PB [email protected] so they can test the whole program on a Windows Vista system.

    Also make sure you have updated to PBWin 8.04 if you have not done so already.

    Here's my altered test code for any Vista users, et.al. to pop in the IDE and try if they want to do so:
    Code:
    GLOBAL priceitems2 AS LONG
    GLOBAL sltype5_lowmap() AS LONG
    GLOBAL pricetime2() AS LONG
    GLOBAL pricedate2() AS STRING
    
    SUB doAnalysis()
        REGISTER i AS LONG
        REDIM sltype5_lowmap(priceitems2)
        ' code to fill sltype5_lowmap(0 - priceitems2) with values here - tested OK
        
        MSGBOX(STR$(priceitems2))
        FOR i = 0 TO priceitems2
            IF pricetime2(i) = 151600 AND pricedate2(i) = "20070605" THEN
                MSGBOX("test output")
                MSGBOX(STR$(priceitems2))
                MSGBOX(STR$(i))
            END IF
        NEXT
    END SUB
    
    FUNCTION PBMAIN () AS LONG       'MainLoop()
        priceitems2 = 115691
        REDIM pricetime2(priceitems2)
        REDIM pricedate2(priceitems2)
        
        pricetime2(1)= 151600
        
        pricedate2(1) = "20070605"
    
        ' code to fill pricetime2() and pricedate2() here - tested OK
    
        doAnalysis()
        ? "Done"
    END FUNCTION

    Leave a comment:


  • Joe Byrne
    replied
    Alex,

    Most of the time, a GPF will occur far after the actual cause. its nearly impossible to say that the specific point that the GPF happens is the cause. Therefore, you want to review your code carefully to see what is happening before it gets to the GPF point. More than likely, you'll find that the index for you array(s) are not what you expect them to be.

    try displaying the UBOUND and LBOUND values before you actually reference them in your sub and see what values you get.

    Leave a comment:


  • Alex Chambers
    replied
    Sorry - I forgot...

    PB WIN 8.0 on Vista

    Leave a comment:


  • Alex Chambers
    started a topic Could this be a PB WIN bug???

    Could this be a PB WIN bug???

    Hello - I am finding some strange behaviour with the following code (a shortened version):

    ===================================

    GLOBAL priceitems2 AS LONG
    GLOBAL sltype5_lowmap() AS LONG
    GLOBAL pricetime2() as LONG
    GLOBAL pricedate2() as STRING

    ===================================

    SUB MainLoop()

    priceitems2 = 115691

    REDIM pricetime2(priceitems2)
    REDIM pricedate2(priceitems2)

    ' code to fill pricetime2() and pricedate2() here - tested OK

    doAnalysis()

    END SUB

    ===================================

    SUB doAnalysis()

    REGISTER i AS LONG

    REDIM sltype5_lowmap(priceitems2)

    ' code to fill sltype5_lowmap(0 - priceitems2) with values here - tested OK

    FOR i = 0 TO priceitems2

    IF pricetime2(i) = 151600 AND pricedate2(i) = "20070605" THEN
    MSGBOX("test output")
    MSGBOX(STR$(priceitems2))
    MSGBOX(STR$(i))

    END IF

    NEXT
    END SUB

    ===================================

    This produces:

    1. msgbox with "test output"
    2. GPF error straight after


    However, if I place this line of code just before the "for i..." loop:

    MSGBOX(STR$(priceitems2))

    I then get the following output:


    1. msgbox with 115691 (the value of priceitems2: correct)
    2. msgbox with "test output"
    3. msgbox with 115691 (the value of priceitems2: correct)
    4. msgbox with "33875" - the value of i: correct


    This is really strange!!! However, it gets wierder:

    I make *no* changes to the code, re-compile and run, and it GPFs before any msgboxes are shown.

    I make *no* changes to the code again, re-compile and run, and the code produces the output as steps 1-4 above with no GPF.


    Why does one GPF and the other not, considering all array indexes are within bounds, and all I am adding is a msgbox before the "for i" loop???

    Either I'm missing something or this is a PB bug?


    Alex
Working...
X