Announcement

Collapse
No announcement yet.

Could this be a PB WIN bug???

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

  • 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

  • #2
    Sorry - I forgot...

    PB WIN 8.0 on Vista

    Comment


    • #3
      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.
      Software makes Hardware Happen

      Comment


      • #4
        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
        Rick Angell

        Comment


        • #5
          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

          Comment


          • #6
            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......)
            hellobasic

            Comment


            • #7
              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

              Comment


              • #8
                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.
                Engineer's Motto: If it aint broke take it apart and fix it

                "If at 1st you don't succeed... call it version 1.0"

                "Half of Programming is coding"....."The other 90% is DEBUGGING"

                "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                Comment


                • #9
                  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
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    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
                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      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
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment

                      Working...
                      X