Could this be a PB WIN bug???

[Alex Chambers]

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

[Alex Chambers]

Sorry - I forgot...

PB WIN 8.0 on Vista

[Joe Byrne]

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.

[Richard Angell]

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:

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

[Alex Chambers]

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

[Edwin Knoppert]

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......)

[Alex Chambers]

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

[Cliff Nichols]

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.

[Michael Mattias]

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.

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

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]

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