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

[Dan Soper]

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:

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

[Lance Edmonds]

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>

[Dan Soper]

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:

#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

[Timm Motl]

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

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

[Dan Soper]

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.