Announcement

Collapse
No announcement yet.

unexpected GPF (aren't they always?)...

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

  • unexpected GPF (aren't they always?)...

    Hi,

    I have a programme which displays a list of image files in a listbox. There is also a static LABEL control which shows a description of the selected image...
    Or it should, at least. This is the function which is supposed to update the description:
    Code:
    SUB UpdateDesc
       'retrieve description of file$
       'and put it into %DESCRIPTION
    
       LOCAL file$, text$
       LOCAL count AS LONG, lp AS LONG, CDImDesc AS LONG
       STATIC flag AS LONG, desclist$()
    
       IF ISFALSE(flag) THEN
          flag = %TRUE
          Count = 1
          CDImDesc = FREEFILE
          OPEN $CDImList FOR INPUT AS CDImDesc
          DIM desclist$(1 TO 3, 1 TO 1)
          LINE INPUT #CDImDesc, text$
          desclist$(1, Count) = PARSE$(text$, $TAB, 1) 'filename
          desclist$(2, Count) = PARSE$(text$, $TAB, 2) 'description
          desclist$(3, Count) = PARSE$(text$, $TAB, 3) 'date
          WHILE NOT EOF(CDImDesc)
                INCR Count
                REDIM PRESERVE desclist$(1 TO 3, 1 TO Count)
                LINE INPUT #CDImDesc, text$
                desclist$(1, Count) = PARSE$(text$, $TAB, 1) 'filename
                desclist$(2, Count) = PARSE$(text$, $TAB, 2) 'description
                desclist$(3, Count) = PARSE$(text$, $TAB, 3) 'date
          WEND
          CLOSE CDImDesc
       END IF
    
       LISTBOX GET TEXT hDlg, %CDList TO file$
       text$ = $NoDesc
       IF LEN(file$) THEN
          FOR lp = 1 TO Count
              IF file$ = desclist$(1, lp) THEN
                 text$ = desclist$(2, lp)
                 EXIT FOR
              END IF
          NEXT
       END IF
    
       CONTROL SET TEXT hDlg, %DESCRIPTION, text$
    
    END SUB
    Descriptions reside in a text file, the format of which is as follows:

    Film1-Image17.jpg Freshwater West 11 June 2000
    Film1-Image18.jpg Skokholm Island 11 June 2000

    i.e. filename then description, then a date, with tabs as delimiters and one line per image. The file currently contains 37 entries.

    The first time the SUB is called, it sets flag to true, and fills desclist$(). The array is static, so it only needs to be filled once.

    Then, when the selected image in the listbox changes, I scan through the array to find the right description, and put that text into the LABEL.
    (At present, the date included in the text file isn't actually used.)

    The problem is that I get a GPF, and I'm not sure why. The error message box says:
    SELECTOR caused an invalid page fault in
    module OLEAUT32.DLL at 0167:7fe81543...
    This appears to be occuring on either the first or possibly the second pass through the WHILE... loop.
    I'm probably missing something obvious, but it's one of the simplest pieces of code I've written, and I can't see any (more!) bugs. Suggestions would be greatly appreciated!

    ------------------
    --Dan
    Dan

  • #2
    The most likely cause is trying to access an array beyond it's bounds. Unfortunately we cannot duplicate your problem to give you an explicit answer as your code snippet is not compilable, and we do not have the data files you are reading from.

    In this case, I suggest you start pruning the code back until the error goes away, or simply step through it in the debugger (I usually use the Animate mode) and it should stop at the point that the GPF occurs.

    Now, it is possible the problem is actually a memory corruption problem caused by faulty code elsewhere in your program (eg, overwriting memory used by this code), but you gotta start looking somewhere.

    I also notice that there is no error testing on your file I/O... what happens if your TXT file is not able to be read?

    Good luck!


    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    Lance
    mailto:[email protected]

    Comment


    • #3
      Hi Lance,

      I didn't post more than that SUB because the entire source is rather large, and without the data files and some other stuff it wouldn't run anyway.

      So, I took your suggestion of letting the debugger play with it. I've found the debugger less than helpful in the past, and my opinion of it hasn't changed - the programme ran in the debugger with no apparent problem... except that the array that the data was being put into remained empty.

      I went back to my preferred debugging technique, scattering MSGBOXes through the suspect areas of code.

      This is where it gets strange - within the WHILE... loop in the source I posted before, the INCR Count statement does what it's supposed to, but the REDIM PRESERVE does *nothing*.
      After the REDIM PRESERVE... statement, UBOUND(desclist$(2)) returns 1. The GPF is then generated when I try to access desclist$(1, 2), as would be expected.

      The following code, intended to simulate (or should that be stimulate?) the problem, compiles and runs properly:
      Code:
      #COMPILE EXE
      OPTION EXPLICIT
      
      FUNCTION PBMAIN
         LOCAL test$(), number AS LONG
      
         DIM test$(1 TO 3, 1 TO 1)
         number = 1
         test$(1, 1) = "test1"
         test$(2, 1) = "test2"
         test$(3, 1) = "test3"
      
         WHILE number < 6
               INCR number
               REDIM PRESERVE test$(1 TO 3, 1 TO number)
               test$(1, number) = "test1"
               test$(2, number) = "test2"
               test$(3, number) = "test3"
         WEND
      
         MSGBOX STR$(number) + $CRLF + STR$(UBOUND(test$(2)))
      
      END FUNCTION
      The messagebox contains

      6
      6

      -exactly as it should.

      I did eventually "fix" the problem, by re-writing the sub so as not to redim the array (open file as BINARY; read all of file into a string; use TALLY to count $CRLF's; DIM array; parse string).

      So the most likely possible cause was a problem elsewhere in the programme, as you suggested. My re-write has stopped the GPF, but I have no idea where the underlying problem is. Or how to find it.
      I don't do anything in the programme which could reasonably be expected to corrupt memory - read a couple of text files; create and manipulate the contents of a couple of DDT listboxes and string arrays; do some file copying/deleting. Nothing exciting.

      Oh, there's no error testing in the code I posted because eventually the programme and its data will reside on a CD - there is no way in which the programme can fail to find the data files. Unless a user decides to copy the exe to their hard disk, in which case they'll only have themselves to blame...
      (ok, maybe I'll put in some code to check that the "current" drive is a CD-ROM )

      ------------------
      --Dan
      Dan

      Comment


      • #4
        Dan...

        The second code example you posted that "ran properly" did not use the same variable declaration for test$() as you
        did for desclist$() in your original code snippet. Your first posting had desclist$() declared as a STATIC array.
        Using LOCAL (or GLOBAL for that matter) lets you REDIM with PRESERVE and avoid the GPF...
        Code:
        #COMPILE EXE
        #INCLUDE "WIN32API.INC"
        
        
        FUNCTION PBMAIN
           LOCAL Count AS LONG
           LOCAL desclist$() ' Use LOCAL instead of STATIC !
           '
           Count = 1
           DIM desclist(1 TO 3, 1 TO Count)
           desclist$(1, Count) = "Image1.bmp"
           desclist$(2, Count) = "My Dog"
           desclist$(3, Count) = "01-01-1980"
           MSGBOX desclist$(1, 1) + $CRLF + desclist$(2, 1) + $CRLF + desclist$(3, 1)
           '
           INCR Count
           REDIM PRESERVE desclist$(1 TO 3, 1 TO Count)
           desclist$(1, Count) = "Image2.bmp"
           desclist$(2, Count) = "My Cat"
           desclist$(3, Count) = "10-19-2000"
           MSGBOX desclist$(1, 1) + $CRLF + desclist$(2, 1) + $CRLF + desclist$(3, 1) + $CRLF+$CRLF + _
                  desclist$(1, 2) + $CRLF + desclist$(2, 2) + $CRLF + desclist$(3, 2)
        END FUNCTION
        The PB Reference Guide does state "REDIM may be used to alter the size of Static and Global arrays". However, you can
        see that it doesn't work properly on STATIC arrays if you're also using PRESERVE in the command.

        Timm

        [This message has been edited by Timm Motl (edited October 19, 2000).]
        mailto:[email protected]
        Tsunami Record Manager

        Comment


        • #5
          Thanks Timm - looks like I was misled by a minor ambiguity in the help file.

          So this means I'm not suffering (necessarily) from a hidden memory leak after all... That's a relief.
          Dan

          Comment

          Working...
          X